jiebi/CodeConvo huggingface dataset:
Change:
<ins> enum Foo { A = foo(), //~ ERROR: type annotations needed B = foo(), //~ ERROR: type annotations needed } const fn foo<T>() -> isize { 0 } fn main() {} </ins>

Discussion:
Following code ICEs on today's nightly ( 2019-09-20): What's peculiar is that no ICE is shown when the enum contains only one item:
Backtrace:
This is because the discriminant assignment code tries to increment the discriminant of the previous variant, which was an error, and thus fails in a different way to the first. However, the code looks like it handles that case, so I'm not yet sure what's going wrong here. Edit: I think there's some state changing inside — the discriminant assignment code seems to be working as expected. is being called with essentially identical arguments, but something about the first error is causing the second one to behave differently.
It's not a regression. Stable shows I don't see how we could be keeping state. Maybe it's happening because there's no "cannot infer type for " error on anything but the first item? So is never evaluated, thus not causing an ICE.
Hmm, perhaps. In that case, it's simplest just to instead.
This , though it does ICE on beta. We now get type inference errors on both variants.
Reopening, as we should have a test.
Change:
assert_eq!(DROPS.load(Ordering::SeqCst), size); } } <ins> #[test] fn test_into_keys() { let vec = vec![(1, 'a'), (2, 'b'), (3, 'c')]; let map: BTreeMap<_, _> = vec.into_iter().collect(); let keys: Vec<_> = map.into_keys().collect(); assert_eq!(keys.len(), 3); assert!(keys.contains(&1)); assert!(keys.contains(&2)); assert!(keys.contains(&3)); } #[test] fn test_into_values() { let vec = vec![(1, 'a'), (2, 'b'), (3, 'c')]; let map: BTreeMap<_, _> = vec.into_iter().collect(); let values: Vec<_> = map.into_values().collect(); assert_eq!(values.len(), 3); assert!(values.contains(&'a')); assert!(values.contains(&'b')); assert!(values.contains(&'c')); } </ins>

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
fn from(err: &LayoutError<'tcx>) -> Self { match err { LayoutError::Unknown(..) | LayoutError::ReferencesError(..) => Self::UnknownLayout, <ins> LayoutError::SizeOverflow(..) => Self::SizeOverflow, </ins> err => unimplemented!("{:?}", err), } }

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. --<!-- 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
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
//! Runtime calls emitted by the compiler. <del> use c_str::ToCStr; </del> <ins> use c_str::CString; use libc::c_char; use cast; use option::Some; </ins> #[cold] #[lang="fail_"]

Discussion:
creates an error string dynamically, then passes it as an unsafe pointer to , which then casts the string to , then to , then throws it to another task. Nominating.
Change:
fn inverse<T>() -> T // this is using ConvertTo as if it were "ConvertFrom<i32>" where i32: ConvertTo<T> { <del> 1i32.convert() </del> <ins> 42.convert() </ins> } ```

Discussion:
I am reading here: I also checked the nightly docs, which are the same. The example says: However, I did not see any other mention of . It seems like it should probably be the name of a formal argument to .
1i32 = one i32. Fonts...
Ouch, I did not see that at all. How about making it "79i32" or something like that?
Alternatively, we could ditch the serifed font.
Change:
ident, is_glob, please_inline, <ins> path, </ins> ) { continue; }

Discussion:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.
Change:
fcx.schedule_drop_mem(scope, dest, e_ty); } <del> adt::trans_set_discr(bcx, repr, addr, discr); </del> <ins> adt::trans_set_discr(bcx, &*repr, addr, discr); </ins> fcx.pop_custom_cleanup_scope(custom_cleanup_scope); <del> return bcx; </del> <ins> // If we don't care about the result drop the temporary we made match dest { SaveIn(_) => bcx, Ignore => { bcx = glue::drop_ty(bcx, addr, ty); base::call_lifetime_end(bcx, addr); bcx } } </ins> }

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is
Change:
use rustc_hir as hir; use rustc_middle::mir::BorrowKind; use rustc_middle::thir::*; <ins> use rustc_middle::ty::print::with_no_trimmed_paths; </ins> use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt}; use rustc_session::lint::builtin::{UNSAFE_OP_IN_UNSAFE_FN, UNUSED_UNSAFE}; use rustc_session::lint::Level;

Discussion:
In some external crate, say : Main crate: : With , this gives the following ICE: <details<summary<strongBacktrace</strong</summary<p</p</detailsThis is because the lint to insert the name in the diagnostic message (this delays a good path bug), then the lint because it's in an external macro, which means we don't emit any diagnostic which triggers the good path bug. This ICE is currently preventing rustc from building with enabled. I see several ways to fix this: don't print the function name. It arguably carries little value, with the span already pointing to the offending function call, and brings THIR unsafeck in line with MIR unsafeck (cc ). 't trim the path. This might lead to longer messages but other lints already do this so it is probably acceptable? 't create the lint if we're in an external macro and we know the lint will be cancelled anyway. It's a little hacky and breaks down if changes are made to lint emission. the lint emission API to allow lint messages to be lazily evaluated. label +A-diagnostics +requires-nightly claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Error: Label thir-unsafeck can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Would not trimming the path also be acceptable ? (via )
It looks like some lints are already not trimming paths so this is probably acceptable? I can do that if that's the preferred option.
claim
Change:
} if let Some(s) = since && s.as_str() == VERSION_" { <del> let version = option_env!("CFG_VERSION").unwrap_or("<current>"); let version = version.split(' ').next().unwrap(); since = Some(Symbol::intern(&version)); </del> <ins> since = Some(rust_version_symbol()); </ins> } match (feature, since) {

Discussion:
with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:
Change:
"x86_64-pc-windows-msvc", "x86_64-rumprun-netbsd", "x86_64-sun-solaris", <ins> "x86_64-pc-solaris", </ins> "x86_64-unknown-cloudabi", "x86_64-unknown-freebsd", "x86_64-unknown-linux-gnu",

Discussion:
There are actually two different generally expected encodings of the host tuple and they're subtly different than what some might expect. For example, 'x8664-sun-solaris' should probably be x8664-pc-solaris. The reason for that is that the encoding schemes are actually: So while 'sparcv9-sun-solaris' is correct because Sun is the (historical) manufacturer of sparc CPUs, 'x8664-sun-solaris' is not, because the MANUFACTURER here is the manufacturer of the CPU not the operating system. There are special cases for this, for example 'x8664-apple-darwin', even though Apple doesn't make x8664 CPUs, but following gcc/clang conventions leads us to x8664-pc-solaris. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
/cc /cc
An interesting discrepancy here is that our target and the LLVM target currently don't match. I'm not sure whether we can/should change anything here for backwards compatibility reasons, though an alias seems fine.
Hi, can I take this issue up? Can someone give a hint on how to fix this? I am a rust beginner, interested in compilers. This would be my first contribution.
as far as I can tell, you should just be able to add a new line under: containing , and then add a new line under: containing: (Sorry for the delay: I only just saw your message.)
claim
I wonder how it's supposed to work? Only x86_64-sun-solaris continues work for me: This change make it harder for Mozilla Firefox to decide which target to use...
I think we may have to introduce some changes in to make rustc try to use the alias. I.e. should try to use the target . I haven't had time to look into what else needs to be changed.
Closing as a duplicate of
Change:
let input = "use asdf::qwop; assert_eq!(2+2, 4);"; let expected = "#![allow(unused)] <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { use asdf::qwop; assert_eq!(2+2, 4);

Discussion:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?
Change:
// except according to those terms. // See comments in Cargo.toml for why this exists <ins> // There's a bug right now where if we pass --extern std=... and we're cross // compiling then this doesn't work with `#[macro_use] extern crate std;`. Work // around this by not having `#[macro_use] extern crate std;` #![no_std] extern crate std; </ins>

Discussion:
This looks weird. Isn't a .dll the right thing for this target? cc
Could you try passing ? Seems like may not be making its way to Cargo, or the shim is really messing up here (probably the latter)

Because that's what the old build system does: but rustbuild and rsbegin.o ends up being an ELF on linux: The fix should be simple in theory. You just have to pass to the in the code linked above. But then you run in problems with the order of the operations: " not found for $TARGET". cc
FWIW, trying to cross compile to i686-pc-windows-gnu I get this: Trying to cross compile to x86_64-pc-windows-gnu results in
Yeah not passing would do it, should be easy to add though! (I think that's all that's necessary)
Actually, the solution is the opposite. rustbuild is building these startup files for linux but it should compile them for windows hence the has to be .
Oh right sorry "it" there was "would cause this problem", we should indeed pass !
Change:
<ins> error[E0594]: cannot assign to immutable static item `S` --> $DIR/thread-local-mutation.rs:11:5 | LL |     S = "after"; //~ ERROR cannot assign to immutable |     ^^^^^^^^^^^ cannot assign error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>

Discussion:
On rustc 1.31.0-nightly ( 2018-10-07) and x8664-unknown-linux-gnu, we see the following surprising behavior: In release mode it seems the write has not happened in the place that it should. Mentioning threadlocal tracking issue: .
Ah, apparently this is missing a . With the behavior is correct. We need to make sure mutating a thread_local static that does not have does not compile.
cc Did fix this by any chance?
It looks like this is fixed on nightly; I'm guessing is the reason. We probably should add some regression tests for the cases listed here.
Change:
<ins> struct Struct { m: Vec<Someunknownname<String, ()>>, //~ ERROR cannot find type `Someunknownname` in this scope //~^ NOTE not found in this scope } struct OtherStruct { //~ HELP you might be missing a type parameter m: K, //~ ERROR cannot find type `K` in this scope //~^ NOTE not found in this scope } fn main() {} </ins>

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
<ins> // build-pass #![allow(incomplete_features)] #![feature(const_generics)] pub struct Vector<T, const N: usize>([T; N]); pub type TruncatedVector<T, const N: usize> = Vector<T, { N - 1 }>; impl<T, const N: usize> Vector<T, { N }> { /// Drop the last component and return the vector with one fewer dimension. pub fn trunc(self) -> (TruncatedVector<T, { N }>, T) { unimplemented!() } } fn vec4<T>(a: T, b: T, c: T, d: T) -> Vector<T, 4> { Vector([a, b, c, d]) } fn main() { let (_xyz, _w): (TruncatedVector<u32, 4>, u32) = vec4(0u32, 1, 2, 3).trunc(); } </ins>

Discussion:
I have the following code: Attempting to use this function, such as in the following manner: causes the compiler to crash with the following backtrace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this was fixed at some point. The following minimal example ICEs on nightly-2019-06-26, but doesn't on nightly-2020-03-11!
I'll look into adding a test for this tomorrow! :)
assign
Change:
#![feature(const_cow_is_borrowed)] #![feature(const_heap)] #![feature(const_mut_refs)] <del> #![feature(const_nonnull_slice_from_raw_parts)] </del> <ins> #![feature(const_slice_from_raw_parts_mut)] </ins> #![feature(const_ptr_write)] #![feature(const_try)] #![feature(core_intrinsics)]

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
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] [ ] 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.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
: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. This will be merged soon.
Change:
Dog { age: x } => {} //~ ERROR pattern does not mention field `name` } match d { <ins> // trailing comma Dog { name: x, } => {} //~ ERROR pattern does not mention field `age` } match d { // trailing comma with weird whitespace Dog { name: x  , } => {} //~ ERROR pattern does not mention field `age` } match d { </ins> Dog {} => {} //~ ERROR pattern does not mention fields `name`, `age` } }

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics
Change:
} } <ins> // #78366: check the reference to the binding is recorded even if the binding is not autorefed async fn h(x: usize) { match x { y if foo().await[y] => (), _ => (), } } async fn i(x: u8) { match x { y if f().await == y + 1 => (), _ => (), } } </ins> fn main() { let _ = g(10); <ins> let _ = h(9); let _ = i(8); </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. --<!-- 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</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .
Change:
|                              +++++++ help: consider relaxing the implicit `Sized` restriction | <del> LL | pub trait Foo<RHS=Self: ?Sized> { |                       ++++++++ </del> <ins> LL | pub trait Foo<RHS: ?Sized=Self> { |                  ++++++++ </ins> error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/issue-28576.rs:5:16

Discussion:
No response No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Another variant of this error I came up with using stable Edit Just tested on stable and . Both produced the same output.
claim
This is only tangentially related but just to give more context to anyone stumbling upon this issue: The diagnostic highlighting the entire path instead of only the type argument is tracked in .
Change:
<ins> error: this must repeat at least once --> $DIR/issue-61033-1.rs:4:34 | LL |     ($x:ident, $($tt:tt)*) => { $($tt)+ } |                                  ^^^^^ error: aborting due to previous error </ins>

Discussion:
Given this test file: stable Rust errors like this: while on 1.36.0-nightly ( 2019-05-21) running on x86_64-unknown-linux-gnu:
caused by cc
Yay, we have a test case.
Hmm... interesting... yeah, I guess we have a test case. I will open a PR to revert and add the test case. Thanks ! But this raises a bigger point that has been growing on me for a while now: there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. Checking that the Kleene operator used in the body is the same as that in the matcher Checking that all meta-variables used in the body are defined and in scope Checking that all meta-variables used in the body are repeating at the right depth Checking that the body of a macro is actually valid rust syntax (to the extent that we can, anyway) So far, I have been holding off on attempting to fix these because they could involve building a whole language, and it seems that at some point we want to just use macros... Thoughts?
Opened
there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. If the defined macro produces an error with any possible input, then we should probably report it at definition time, at least as a quality of implementation measure (perhaps as a warning for a start). I have more confidence in reporting errors related to the macro definition language itself (meta-variables, repetitions, etc.), than in errors for produced tokens (which are not necessarily supposed to be Rust code, with eager expansion they may be consumed by another macro, for example).
Ok, makes sense. I will open another issue with these items so we can track them.