jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:4:32 | LL |     let strings: [String; 5] = [String::new(); 5]; |                                ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = note: the `Copy` trait is required because the repeated element will be copied = help: consider creating a new `const` item and initializing with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` = help: create an inline `const` block, see PR #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut my_stuff = std::collections::HashMap::new(); my_stuff.insert(0i, 42i); let (_, thing) = my_stuff.iter().next().unwrap(); my_stuff.clear(); //~ ERROR cannot borrow println!("{}", *thing); } </ins>

Discussion:
Sorry, I'm not sure how to describe this very well in a sentence. I am able to mutably borrow the innermost values of a , delete the values, then reference them after they were deleted. This code compiles, runs, and barfs out strange numbers.
Little bit shorter example, without mutable borrows. But still fails to freeze :
nominating for 1.0 P-backcompat-lang
though this may be a library issue
weird This code is also valid: This is because the hashmap iterator just wraps the rawtable iterator, which just defers to the RawBuckets iterator, which is just a wrapper around two *mut's. That is, literally none of these iterators actually borrows the hashmap. Presumably this is fixable by taking a useless reference somewhere. The other thing I'm seeing is that there's , but the signature for Hashmap's iterator function is . How is this lifetime being elided? Is it doing the same thing as , or is something else happening? CC
Yep, it's eliding !
So there's two bugs here: the iterator doesn't borrow the map, and the references are being yielded as .
Assigning P-backcompat-libs, 1.0
thanks for fixing this! Great job!
Change:
/// /// [`copied`]: trait.Iterator.html#method.copied /// [`Iterator`]: trait.Iterator.html <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> #[must_use = "iterators are lazy and do nothing unless consumed"] #[derive(Clone, Debug)] pub struct Copied<I> { it: I, } impl<I> Copied<I> { pub(super) fn new(it: I) -> Copied<I> { Copied { it } } } <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> impl<'a, I, T: 'a> Iterator for Copied<I> where I: Iterator<Item=&'a T>, T: Copy {

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
STD_REF_MUT_REGEX = re.compile(r"^(core::([a-z_]+::)+)RefMut<.+>$") STD_REF_CELL_REGEX = re.compile(r"^(core::([a-z_]+::)+)RefCell<.+>$") STD_NONZERO_NUMBER_REGEX = re.compile(r"^(core::([a-z_]+::)+)NonZero<.+>$") <ins> STD_PATHBUF_REGEX = re.compile(r"^(std::([a-z_]+::)+)PathBuf$") STD_PATH_REGEX =  re.compile(r"^&(mut )?(std::([a-z_]+::)+)Path$") </ins> TUPLE_ITEM_REGEX = re.compile(r"__d+$")

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
w.write_str(",n"); } <del> if variants_stripped { </del> <ins> if variants_stripped && !it.is_non_exhaustive() { </ins> w.write_str("    // some variants omittedn"); } if toggle {

Discussion:
<table<tr<thcode</th<thrustdoc</th</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr</tableWould it be reasonable for Rustdoc to produce exactly the same output for and ? I think so. These two types have an identical public API. Separately, would it be reasonable for Rustdoc to produce exactly the same output for and ? Whether that means printing a synthetic attribute on instead of the comment, or some other approach that unifies all three of these outputs. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
IMHO, for both is more clear. It better conveys meaning. I'm happy to work on this but I've never touched rustdoc before so I might need some help. claim EDIT: is it acceptable to literally a new attribute onto ?
I think it's important that the docs not disagree with behavior users can observe from the compiler. So we shouldn't document a attribute when none exists because a user could write an exhaustive match and not get a compile error (even though they might have had to look at the source to do so). I think it would be reasonable for Enum2 and Enum3 to render as Enum2 is today: <img width=300 src="https://user-"For Enum1, I think there should be a doc lint warning if there is a variant without the enum being marked .
I agree, a doc lint sounds like the best idea because semantically is even if not technically so. I see that you are the reviewer on the linked PR, I've marked it as a draft for now and will re-implement with your suggestion. I assume that broadly agrees from the OP?
Change:
#![feature(thin_box)] #![feature(strict_provenance)] #![feature(drain_keep_rest)] <ins> #![feature(local_waker)] </ins> #![allow(internal_features)] #![deny(fuzzy_provenance_casts)] #![deny(unsafe_op_in_unsafe_fn)]

Discussion:
I would expect this to run to completion: On stable, it does: But not on current nightly: Interestingly, it works ok without cargo: The cargo project isn't special though: OS: macOS 13.6.3
cc I guess?
The internal function uses const promotion for the vtable in two places, once at initial construction and another when cloning. Maybe that results in two differently-addressed vtables.
I gave this a shot in . But without a language feature for statics with type parameters, we are not seeing a reliable way to restore 's functionality. Let's consider reverting . Having be a handful of CPU instructions faster but way more often wrong is not useful.
Change:
run-make/issue-84395-lto-embed-bitcode/Makefile run-make/jobserver-error/Makefile run-make/libs-through-symlinks/Makefile <del> run-make/macos-deployment-target/Makefile </del> run-make/split-debuginfo/Makefile run-make/symbol-mangling-hashed/Makefile run-make/translation/Makefile

Discussion:
Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .
Change:
} else { ast::InlineAsmOperand::InOut { reg, expr, late: true } } <del> } else if p.eat(&token::Ident(kw::Const, false)) { </del> <ins> } else if p.eat_keyword(kw::Const) { </ins> let expr = p.parse_expr()?; ast::InlineAsmOperand::Const { expr } <del> } else if p.eat(&token::Ident(sym::sym, false)) { </del> <ins> } else if p.eat_keyword(sym::sym) { </ins> let expr = p.parse_expr()?; match expr.kind { ast::ExprKind::Path(..) => {}

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
<ins> #![feature(dyn_star)] //~^ WARN the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes union Union { x: usize, } trait Trait {} impl Trait for Union {} fn bar(_: dyn* Trait) {} fn main() { bar(Union { x: 0usize }); //~^ ERROR `Union` needs to have the same ABI as a pointer } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- In particular, this also happens with . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label F-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?
Change:
<ins> // Regression test for ICE #124848 // Tests that there is no ICE when a cast // involves a type with error use std::cell::Cell; struct MyType<'a>(Cell<Option<&'unpinned mut MyType<'a>>>, Pin); //~^ ERROR use of undeclared lifetime name `'unpinned` //~| ERROR cannot find type `Pin` in this scope fn main() { let mut unpinned = MyType(Cell::new(None)); //~^ ERROR his struct takes 2 arguments but 1 argument was supplied let bad_addr = &unpinned as *const Cell<Option<&'a mut MyType<'a>>> as usize; //~^ ERROR use of undeclared lifetime name `'a` //~| ERROR use of undeclared lifetime name `'a` //~| ERROR casting `&MyType<'_>` as `*const Cell<Option<&mut MyType<'_>>>` is invalid } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: should be sized but is not?', 'error: internal compiler error: should be sized but is not?' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this seems to bisect to fyi
claim
Change:
//! This test checks that opaque type collection doesn't try to normalize the projection //! without respecting its binders (which would ICE). //! Unfortunately we don't even reach opaque type collection, as we ICE in typeck before that. <del> // known-bug: #109281 // failure-status: 101 // error-pattern:internal compiler error // normalize-stderr-test "internal compiler error.*" -> "" // normalize-stderr-test "DefId([^)]*)" -> "..." // normalize-stderr-test "nerror: internal compiler error.*nn" -> "" // normalize-stderr-test "note:.*unexpectedly panicked.*nn" -> "" // normalize-stderr-test "note: we would appreciate a bug report.*nn" -> "" // normalize-stderr-test "note: compiler flags.*nn" -> "" // normalize-stderr-test "note: rustc.*running on.*nn" -> "" // normalize-stderr-test "thread.*panicked.*:n.*n" -> "" // normalize-stderr-test "stack backtrace:n" -> "" // normalize-stderr-test "sd{1,}: .*n" -> "" // normalize-stderr-test "s at .*n" -> "" // normalize-stderr-test ".*note: Some details.*n" -> "" // normalize-stderr-test "nn[ ]*n" -> "" // normalize-stderr-test "compiler/.*: projection" -> "projection" // normalize-stderr-test ".*omitted d{1,} frame.*n" -> "" // normalize-stderr-test "error: [sn]*query stack" -> "error: query stack" // normalize-stderr-test "[ns]*nquery stack during panic:" -> "query stack during panic:" </del> <ins> //! See #109281 for the original report. </ins> // edition:2018 <ins> // error-pattern: expected generic lifetime parameter, found `'a` </ins> #![feature(type_alias_impl_trait)] #![allow(incomplete_features)]

Discussion:
Found this while minimizing :smile: So maybe related? didn't seem like duplicates. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +S-bug-has-mcve +F-typealiasimpl_trait
Regression in nightly-2022-07-01 reproduced based of a modifiction of which does not need any feature gates and crashes stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that we handle projection types which wind up important for // resolving methods. This test was reduced from a larger example; the // call to `foo()` at the end was failing to resolve because the // winnowing stage of method resolution failed to handle an associated // type projection. #![feature(associated_types)] trait Hasher { type Output; fn finish(&self) -> Self::Output; } trait Hash<H: Hasher> { fn hash(&self, h: &mut H); } trait HashState { type Wut: Hasher; fn hasher(&self) -> Self::Wut; } struct SipHasher; impl Hasher for SipHasher { type Output = u64; fn finish(&self) -> u64 { 4 } } impl Hash<SipHasher> for int { fn hash(&self, h: &mut SipHasher) {} } struct SipState; impl HashState for SipState { type Wut = SipHasher; fn hasher(&self) -> SipHasher { SipHasher } } struct Map<S> { s: S, } impl<S> Map<S> where S: HashState, <S as HashState>::Wut: Hasher<Output=u64>, { fn foo<K>(&self, k: K) where K: Hash< <S as HashState>::Wut> {} } fn foo<K: Hash<SipHasher>>(map: &Map<SipState>) { map.foo(22); } fn main() {} </ins>

Discussion:
(or so niko told me) I believe this code should compile, but it does not compile. Trawling through some logs made Niko think that something wasn't normalized one way or the other, so opening an issue! cc cc

Right now we don't normalize impl bounds during method probing, which means that the winnow stage may not work great when those bounds involve associated types. I think with the new setup we should be able to do this but didn't have time to test. Search for the FIXME in
Change:
<ins> fn main() { g((), ()); //~^ ERROR this function takes 6 arguments but 2 arguments were supplied } pub fn g(a1: (), a2: bool, a3: bool, a4: bool, a5: bool, a6: ()) -> () {} </ins>

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
extern crate no_method_suggested_traits; <ins> struct Foo; enum Bar { X } </ins> mod foo { trait Bar { fn method(&self) {}

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
<ins> // regression test for #83466- tests that generic arg mismatch errors between // consts and types are not supressed when there are explicit late bound lifetimes struct S; impl S { fn func<'a, U>(self) -> U { todo!() } } fn dont_crash<'a, U>() { S.func::<'a, 10_u32>() //~^ WARNING cannot specify lifetime arguments explicitly if late bound lifetime parameters are present //~^^ WARNING this was previously accepted by //~^^^ ERROR constant provided when a type was expected [E0747] } fn main() {} </ins>

Discussion:
This is ICE since 1.50.0, error -ICE. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-03-17 regressed nightly: nightly-2020-11-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Thanks for bisecting, I believe is the cause.
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
claim
Change:
use std::ops::Bound; <del> use crate::const_eval::{is_const_fn, is_min_const_fn}; </del> <ins> use crate::const_eval::is_min_const_fn; </ins> use crate::util; pub struct UnsafetyChecker<'a, 'tcx> {

Discussion:
Some operations, such as raw pointer comparisons, require when inside a const context. To my knowledge, none of these operations have been const-stabilized. Accordingly, the fails to compile due to a missing unsafe block. However, the check does not run for functions. The following : This is an easy problem to fix, but the root cause here is poor naming. Specifically, should be renamed and should be . We have had other issues due to this in the past. cc to weigh in on the renaming.
Yeah I recall being confused by those names in the past, too. Definite :+1: for changing them. As for concrete proposals, I don't actually remember what these queries are doing, but your suggestions sound reasonable. :)
Oh, the names are different than in the email I got because you edited.^^ So does take the context (feature flags etc) into account? The name sounds like it would. What about , to make it a bit shorter?
Damn. I was hoping no one would catch me :smile:. would indeed take feature flags into account to mirror the current behavior of . I originally had , but that's not really correct, since it would also return if the function was unstable but the requisite feature flags were set.
Change:
return; } <del> if intrinsic == sym::assert_zero_valid && !fx.tcx.permits_zero_init(layout) { </del> <ins> if intrinsic == sym::assert_zero_valid && !fx.tcx.permits_zero_init(fx.param_env().and(layout)) { </ins> with_no_trimmed_paths!({ crate::base::codegen_panic( fx,

Discussion:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.