jiebi/CodeConvo huggingface dataset:
Code change:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to

Related discussion:
text: error[E0364]: `foo` is private, and cannot be re-exported <del> --> $DIR/reexports.rs:6:17 </del> <ins> --> $DIR/reexports.rs:8:17 </ins> | LL |         pub use super::foo; |                 ^^^^^^^^^^ | note: consider marking `foo` as `pub` in the imported module <del> --> $DIR/reexports.rs:6:17 </del> <ins> --> $DIR/reexports.rs:8:17 </ins> | LL |         pub use super::foo; |                 ^^^^^^^^^^ <del> error: A non-empty glob must import something with the glob's visibility --> $DIR/reexports.rs:7:17 | LL |         pub use super::*; |                 ^^^^^^^^ </del> error[E0603]: module `foo` is private <del> --> $DIR/reexports.rs:28:15 </del> <ins> --> $DIR/reexports.rs:33:15 </ins> | LL |     use b::a::foo::S; |               ^^^ error[E0603]: module `foo` is private <del> --> $DIR/reexports.rs:29:15 </del> <ins> --> $DIR/reexports.rs:34:15 </ins> | LL |     use b::b::foo::S as T; |               ^^^ <del> error: aborting due to 4 previous errors </del> <ins> warning: glob import doesn't reexport anything because no candidate is public enough --> $DIR/reexports.rs:9:17 | LL |         pub use super::*; |                 ^^^^^^^^ | note: lint level defined here --> $DIR/reexports.rs:1:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> Some errors have detailed explanations: E0364, E0603. For more information about an error, try `rustc --explain E0364`.
Code change:
Found with the help of .
There's two slicing operations in . I'm trying to figure out how a non-boundary index could be appearing in there... maybe is calling with a span that begins at index 10? (where does this come from? ?) Building a debug compiler to check those log statements... Edit: Building the debug compiler was a bust. Embarassingly, things seem to have changed and I don't know how to get those debug macros to fire in the current compiler.
do you mean you were using and not seeing debug output? If so, that is because the environment variable name under was changed to . (I make this mistake pretty much every day due to muscle memory.) As an example, here is the tail of my log output:
triage: P-medium. Removing nomination.
This was broken between 1.15 and 1.16, but those are so old and the nature of the ICE itself has changed from 1.28 to 1.29, so I do not think bisection would be worthwhile.
<details<summaryOfftopic</summary : Thanks. Unfortunately, I did guess the name of after didn't work, and all it showed me was this: I set in my before building, and didn't see anything else in there. (I recall that and used to be but it is no longer, so I did not enable it.) </details
Okay, I did the following evil, evil thing: <details<summaryPure evil, do not open</summary</detailsAnd acquired the following backtrace of when the span was first constructed: It also gets constructed a second time: <details<summarySecond backtrace</summary(the region of the backtrace that differs between the two is items 22-29 in the first one, or 22-25 in the second) </detailsSome interesting spots from here: This is clearly where the value of 10 is created: calls this if there are no remaining tokens and it still hasn't seen the closing delimiter (it seems to have as an unstated precondition that the closing delimiter must exist). Here's the innermost bit that's specific to parsing. Doesn't look that odd...
I’m not familiar with I tend to list (comma separated) module paths in my own use of RUSTCLOG; did you try that? You can see an example in the transcript I gave in my comment above
Oh. (I'm so used to prompts I didn't notice you included the command!). Yeah, that was the issue.
Same ICE occurs with: Which returns:
could you post a base64-encoded version of your ? When I copy/paste what you've posted above, I don't see a compiler crash, presumably because some non-ascii characters are getting lost.
My bad
Hm, the example from hasn't been fixed?
Seems so, on the current nightly:
I guess my fix would help. I'll get some time to test it out.
Confirmed that my fix fixed this issue, I also add this unit test in this PR:

Related discussion:
text: <ins> // ignore-tidy-trailing-newlines // error-pattern: aborting due to 3 previous errors y![ Ϥ, </ins>  No newline at end of file
Code change:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

Related discussion:
text: self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }
Code change:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>
Code change:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>
Code change:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

Related discussion:
text: <ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>
Code change:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

Related discussion:
text: <ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>
Code change:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>
Code change:
The following code () leads to an ICE: Broken since 1.32.0 up to the current nightly, earlier versions are not affected. <details<summaryBacktrace of the nightly build</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels to +T-compiler, +A-diagnostics, +A-parser, +I-ICE
claim
you will need to change the line to bubble the error up: Once you've done that code change create a new test file in .

Related discussion:
text: F: Fn(&token::Token) -> bool { let attrs = self.parse_arg_attributes()?; <del> if let Ok(Some(mut arg)) = self.parse_self_arg() { </del> <ins> if let Some(mut arg) = self.parse_self_arg()? { </ins> arg.attrs = attrs.into(); return self.recover_bad_self_arg(arg, is_trait_item); }
Code change:
The following code () leads to an ICE: Broken since 1.32.0 up to the current nightly, earlier versions are not affected. <details<summaryBacktrace of the nightly build</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels to +T-compiler, +A-diagnostics, +A-parser, +I-ICE
claim
you will need to change the line to bubble the error up: Once you've done that code change create a new test file in .

Related discussion:
text: <ins> // Regression test for issue #62660: if a receiver's type does not // successfully parse, emit the correct error instead of ICE-ing the compiler. struct Foo; impl Foo { pub fn foo(_: i32, self: Box<Self) {} //~^ ERROR expected one of `!`, `(`, `+`, `,`, `::`, `<`, or `>`, found `)` } fn main() {} </ins>
Code change:
The following code () leads to an ICE: Broken since 1.32.0 up to the current nightly, earlier versions are not affected. <details<summaryBacktrace of the nightly build</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels to +T-compiler, +A-diagnostics, +A-parser, +I-ICE
claim
you will need to change the line to bubble the error up: Once you've done that code change create a new test file in .

Related discussion:
text: <ins> error: expected one of `!`, `(`, `+`, `,`, `::`, `<`, or `>`, found `)` --> $DIR/issue-62660.rs:7:38 | LL |     pub fn foo(_: i32, self: Box<Self) {} |                                      ^ expected one of 7 possible tokens here error: aborting due to previous error </ins>
Code change:
Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in

Related discussion:
text: /// consolidate multiple unresolved import errors into a single diagnostic. fn finalize_import(&mut self, import: &'b Import<'b>) -> Option<UnresolvedImportError> { let orig_vis = import.vis.replace(ty::Visibility::Invisible); <ins> let orig_blacklisted_binding = match &import.kind { ImportKind::Single { target_bindings, .. } => { Some(mem::replace(&mut self.r.blacklisted_binding, target_bindings[TypeNS].get())) } _ => None, }; </ins> let prev_ambiguity_errors_len = self.r.ambiguity_errors.len(); let path_res = self.r.resolve_path( &import.module_path,
Code change:
Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in

Related discussion:
text: import.crate_lint(), ); let no_ambiguity = self.r.ambiguity_errors.len() == prev_ambiguity_errors_len; <ins> if let Some(orig_blacklisted_binding) = orig_blacklisted_binding { self.r.blacklisted_binding = orig_blacklisted_binding; } </ins> import.vis.set(orig_vis); if let PathResult::Failed { .. } | PathResult::NonModule(..) = path_res { // Consider erroneous imports used to avoid duplicate diagnostics.
Code change:
Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in

Related discussion:
text: <ins> // check-pass mod m { pub enum Same { Same, } } use m::*; // The variant `Same` introduced by this import is not considered when resolving the prefix // `Same::` during import validation (issue #62767). use Same::Same; fn main() {} </ins>
Code change:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc

Related discussion:
text: let ret = f(self); let last_token = if self.token_cursor.stack.len() == prev { &mut self.token_cursor.frame.last_token <ins> } else if self.token_cursor.stack.get(prev).is_none() { // This can happen due to a bad interaction of two unrelated recovery mechanisms with // mismatched delimiters *and* recovery lookahead on the likely typo `pub ident(` // (#62881). return Ok((ret?, TokenStream::new(vec![]))); </ins> } else { &mut self.token_cursor.stack[prev].last_token };
Code change:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc

Related discussion:
text: // Pull out the tokens that we've collected from the call to `f` above. let mut collected_tokens = match *last_token { LastToken::Collecting(ref mut v) => mem::take(v), <del> LastToken::Was(_) => panic!("our vector went away?"), </del> <ins> LastToken::Was(ref was) => { let msg = format!("our vector went away? - found Was({:?})", was); debug!("collect_tokens: {}", msg); self.sess.span_diagnostic.delay_span_bug(self.token.span, &msg); // This can happen due to a bad interaction of two unrelated recovery mechanisms // with mismatched delimiters *and* recovery lookahead on the likely typo // `pub ident(` (#62895, different but similar to the case above). return Ok((ret?, TokenStream::new(vec![]))); } </ins> }; // If we're not at EOF our current token wasn't actually consumed by
Code change:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc

Related discussion:
text: <ins> fn main() {} fn f() -> isize { fn f() -> isize {} pub f< //~^ ERROR missing `fn` or `struct` for function or struct definition //~| ERROR mismatched types //~ ERROR this file contains an un-closed delimiter </ins>
Code change:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc

Related discussion:
text: <ins> error: this file contains an un-closed delimiter --> $DIR/issue-62881.rs:6:53 | LL | fn f() -> isize { fn f() -> isize {} pub f< |                 - un-closed delimiter ... LL | |                                                     ^ error: missing `fn` or `struct` for function or struct definition --> $DIR/issue-62881.rs:3:41 | LL | fn f() -> isize { fn f() -> isize {} pub f< |                                         ^ error[E0308]: mismatched types --> $DIR/issue-62881.rs:3:29 | LL | fn f() -> isize { fn f() -> isize {} pub f< |                      -      ^^^^^ expected isize, found () |                      | |                      this function's body doesn't return | = note: expected type `isize` found type `()` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc

Related discussion:
text: <ins> fn main() {} fn v() -> isize { //~ ERROR mismatched types mod _ { //~ ERROR expected identifier pub fn g() -> isizee { //~ ERROR cannot find type `isizee` in this scope mod _ { //~ ERROR expected identifier pub    g() -> is //~ ERROR missing `fn` for function definition (), w20); } (), w20); //~ ERROR expected item, found `;` } </ins>