jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0600]: cannot apply unary operator `-` to type `usize` --> $DIR/unsigned-literal-negation.rs:2:13 | LL |     let x = -1 as usize; |             ^^ |             | |             cannot apply unary operator `-` |             help: you may have meant the maximum value of `usize`: `usize::MAX` | = note: unsigned values cannot be negated error[E0600]: cannot apply unary operator `-` to type `usize` --> $DIR/unsigned-literal-negation.rs:3:13 | LL |     let x = (-1) as usize; |             ^^^^ |             | |             cannot apply unary operator `-` |             help: you may have meant the maximum value of `usize`: `usize::MAX` | = note: unsigned values cannot be negated error[E0600]: cannot apply unary operator `-` to type `u32` --> $DIR/unsigned-literal-negation.rs:4:18 | LL |     let x: u32 = -1; |                  ^^ |                  | |                  cannot apply unary operator `-` |                  help: you may have meant the maximum value of `u32`: `u32::MAX` | = note: unsigned values cannot be negated error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0600`. </ins>

Discussion:
Code: Playground: Error message: Somehow, in one case this in the expression is unsigned, but in the other case it is signed and everything is fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For the compiler has to suggest to replace it with . The compiler should also suggest to replace with , to remove some hard "as" casts from the code.
claim
I think this is more appropriate as a clippy lint, opened
Change:
// Forward test filters. cargo.arg("--").args(builder.config.cmd.test_args()); <del> add_flags_and_try_run_tests(builder, &mut cargo.into()); </del> <ins> // This can NOT be `add_flags_and_try_run_tests` since the Miri test runner // does not understand those flags! let mut cargo = Command::from(cargo); builder.run(&mut cargo); </ins> // # Run `cargo miri test`. // This is just a smoke test (Miri's own CI invokes this in a bunch of different ways and ensures

Discussion:
As the title says - Miri UI tests aren't run when invoked through x.py, or on CI: The actual issue appears to be that in the miri directory expects no non-filter args to be passed to it when being run, but the args are getting passed. I was trying to test miri locally, and I ran the command . I expected the miri UI tests to get run, but instead, they were all always getting filtered out, despite not passing a filter. After looking into it a bit, I discovered the filter vector was always , and decided to check whether bors was running them.
This seems ... pretty unfortunate :sweat: cc I know miri is nightly only but it makes me pretty uncomfortable to be shipping tools that aren't running tests, even if rust-lang/miri is still running the tests.
If my shell history is anything to go by, this is recent breakage, and used to run all of Miri's tests.
Yea, this is not breakage on the miri side afaict, but must be a change on the cargo or bootstrap side. I'm fine fixing this on our side tho. I can replicate the behaviour of the default test runner and adjust the wrappers in the miri repo to insert that
For making it follow normal behavior, I'm just replacing the in compiletest with for now. I'd be willing to PR this change as a standalone if desired.
Thanks! That would be great
Yeah I am pretty sure I tested this when we changed Miri to a subtree, and it worked back then. How does looking for help? Looks to me like we'd have to know exactly which flags the regular test runner understands and parse them all the same way. E.g. should apply the filer but should not. Which is of course ridiculous. Can we stop bootstrap from passing wrong flags to test runners?
I suggest that we change the test runner argument parsing to error out if there is any filter starting with -- except after a . So, something like:
The source of the regression is Meanwhile should fix bootstrap invoking the Miri test suite.
Change:
fn no_break_in_async_block() { async { <del> break 0u8; //~ ERROR `break` inside of an `async` block </del> <ins> break 0u8; //~ ERROR `break` inside `async` block </ins> }; } fn no_break_in_async_block_even_with_outer_loop() { loop { async { <del> break 0u8; //~ ERROR `break` inside of an `async` block </del> <ins> break 0u8; //~ ERROR `break` inside `async` block </ins> }; } }

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error[E0277]: the size for values of type `dyn ToString` cannot be known at compilation time --> $DIR/issue-58355.rs:5:14 | LL |     x = Some(Box::new(callback)); |              ^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: within `fn() -> dyn ToString`, the trait `Sized` is not implemented for `dyn ToString` = note: required because it appears within the type `fn() -> dyn ToString` = note: required for the cast from `fn() -> dyn ToString` to the object type `dyn Fn() -> (dyn ToString + 'static)` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Hello, I am trying to implement this trait: I get a compiler panic error: internal compiler error: unexpected panic I try to compile it for target=wasm32-unknown-unknown note: rustc 1.32.0 ( 2019-01-16) running on x86_64-pc-windows-msvc note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib
Can you provide a self-contained example that reproduces the ICE?
Hello, This is the shortest example I could create: If you just build this you should get the error. It looks like it works? when not in lib mode, not sure
Even shorter:
<strikeBug was introduced between 1.23 and 1.24 (...)</strikeBetween 2017-11-20 and 2017-11-21 (...)
cc based on your commits that day ^^
That example should not type-check, you're assigning a where a is expected. cc
Using , we have , before then it was rejected due to syntax being unstable: 1.271.281.301.32
You can just remove the keyword, it really shouldn't matter. Btw, the minimized repro can be minimized further by removing the (rather heavy) : And we can also get rid of : is , none of this can work. So the real question is how does this ICE before emitting a type-checking error?
Okay, so there are two parts to this: the associated type of doesn't require implements the trait, so can be unsized to So this has a reason to type-check, despite being very confusing. We can make this simpler by using pointers: This way, we have , so can be unsized to . But it's impossible for the return type of a function, even with unsized rvalues, to be (i.e. we have no mechanism for supporting that), and here I think at the very least the vtable of has to have a shim that would need to return a return type (, i.e. in the original repro), so we ICE. If we don't want to enforce that return types are in pointers or trait objects methods, this case will continue ICE-ing.
The original problem is clearer if we add the keyword: You can fix your code by putting a around the return type of this , or figure out some other way to do it.

If you want to make sure you find such problems, try to write function that is has implements the right traits, e.g. . That will error because the return type of a function with a body must be .
What alternative do we have?
Thank you , I will look into an alternative
Reproduces () as of 2020-03-10.
modify labels: +regression-from-stable-to-stable Still reproduces with stable/beta/nightly `
Assigning .
The latest nightly fixes the ICE, marking as .
Change:
<ins> #![crate_name = "foo"] // @has foo/struct.Foo.html // @has - '//h2[@id="fields"]' 'Tuple Fields' // @has - '//h3[@class="sidebar-title"]/a[@href="#fields"]' 'Tuple Fields' // @has - '//*[@id="structfield.0"]' '0: u32' // @has - '//*[@id="main"]/div[@class="docblock"]' 'hello' // @!has - '//*[@id="structfield.1"]' // @has - '//*[@id="structfield.2"]' '2: char' // @has - '//*[@id="structfield.3"]' '3: i8' // @has - '//*[@id="main"]/div[@class="docblock"]' 'not hello' pub struct Foo( /// hello pub u32, char, pub char, /// not hello pub i8, ); // @has foo/enum.Bar.html // @has - '//pre[@class="rust enum"]' 'BarVariant(String),' // @matches - '//*[@id="variant.BarVariant.fields"]/h3' '^Tuple Fields of BarVariant$' // @has - '//*[@id="variant.BarVariant.field.0"]' '0: String' // @has - '//*[@id="variant.BarVariant.fields"]//*[@class="docblock"]' 'Hello docs' // @matches - '//*[@id="variant.FooVariant.fields"]/h3' '^Fields of FooVariant$' pub enum Bar { BarVariant( /// Hello docs String ), FooVariant { /// hello x: u32, }, } </ins>

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
ident: Ident, has_sub: bool, ) -> Option<Res> { <ins> // An immutable (no `mut`) by-value (no `ref`) binding pattern without // a sub pattern (no `@ $pat`) is syntactically ambiguous as it could // also be interpreted as a path to e.g. a constant, variant, etc. let is_syntactic_ambiguity = !has_sub && bm == BindingMode::ByValue(Mutability::Not); </ins> let ls_binding = self.resolve_ident_in_lexical_scope(ident, ValueNS, None, pat.span)?; let (res, binding) = match ls_binding { <del> LexicalScopeBinding::Item(binding) if binding.is_ambiguity() => { </del> <ins> LexicalScopeBinding::Item(binding) if is_syntactic_ambiguity && binding.is_ambiguity() => { </ins> // For ambiguous bindings we don't know all their definitions and cannot check // whether they can be shadowed by fresh bindings or not, so force an error. <ins> // issues/33118#issuecomment-233962221 (see below) still applies here, // but we have to ignore it for backward compatibility. </ins> self.r.record_use(ident, ValueNS, binding, false); return None; }

Discussion:
For example: https://crater- https://crater- cc
This is a regression from produced an ambiguity error even if the binding is syntactically unambiguous (e.g. like in the example above) for some future-compatibility reasons (), but it can be easily tweaked to not produce it because backward-compatibility is more important.
Fixed in
Change:
pub mod primitive_docs; pub mod style; pub mod target_specific_tests; <ins> pub mod tests_placement; </ins> pub mod ui_tests; pub mod unit_tests; pub mod unstable_book;

Discussion:
A PR modifying an existing test now has a merge conflict e.g. but a PR adding a new test doesn't e.g. , and I'm worried if a new test is to by accident. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Add a new module to src/tools/tidy, then call the check from See the surrounding code for examples of how tidy checks work.
I am confused as to why this was not a blocker for moving the tests
"I didn't think of it"
claim
Change:
rustc_span::create_session_if_not_set_then(edition, |_| { use rustc_errors::emitter::{Emitter, EmitterWriter}; use rustc_errors::Handler; <del> use rustc_parse::maybe_new_parser_from_source_str; </del> use rustc_parse::parser::ForceCollect; <del> use rustc_session::parse::ParseSess; </del> use rustc_span::source_map::FilePathMapping; let filename = FileName::anon_source_code(s);

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
#![feature(const_ptr_offset)] #![feature(const_trait_impl)] #![feature(const_likely)] <ins> #![feature(core_ffi_c)] </ins> #![feature(core_intrinsics)] #![feature(core_private_bignum)] #![feature(core_private_diy_float)]

Discussion:
This causes a crash when trying to test libcore with cgclif, as Cranelift doesn't allow incompatible definitions of the same function. While this currently works for cgllvm, according to it is likely to become forbidden with cg_llvm too.
modify labels:+A-cranelift
Change:
let ty = tcx.type_of(def_id); let arg_count = GenericArgCountResult { <del> explicit_late_bound: ExplicitLateBound::No, </del> <ins> explicit_late_bound, </ins> correct: if infer_args_for_err.is_empty() { Ok(()) } else {

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:
<ins> #![feature(no_core)] #![feature(lang_items)] #![no_core] #[cfg(target_os = "linux")] #[link(name = "c")] extern {} #[lang = "start"] fn start<T>(_main: fn() -> T, _argc: isize, _argv: *const *const u8) -> isize { //~^ ERROR: incorrect number of parameters for the `start` lang item 40+2 } #[lang = "sized"] pub trait Sized {} #[lang = "copy"] pub trait Copy {} #[lang = "drop_in_place"] #[allow(unconditional_recursion)] pub unsafe fn drop_in_place<T: ?Sized>(to_drop: *mut T) { drop_in_place(to_drop) } #[lang = "add"] trait Add<RHS> { type Output; fn add(self, other: RHS) -> Self::Output; } impl Add<isize> for isize { type Output = isize; fn add(self, other: isize) -> isize { self + other } } fn main() {} </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</details
A "fix" for that code is to add however I don't want to get an ICE but a nice error.
The error comes from I think. If you weren't using hitting this case would be a genuine bug in rustc. Turning it from an ICE into a nice error would require special casing integer types to not ICE here. In general you should expect to see internal compiler errors when you mess up with . In some cases it is feasible to give nice errors but I think this is not such a case.
Thanks! You may close if you think there is nothing you can do.
I am by no means familiar with the relevant code, but this would seem more like a basis for making this a than closing it entirely. As in, it would be nice if there was a way to fix this, but we don't know what it is and it's not really a priority.
Triage: Fixed since nightly-2023-01-04, marking as .
Change:
<ins> error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-42060.rs:13:23 | LL |     let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant |                       ^^^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-42060.rs:19:13 | LL |     <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant |             ^ non-constant value error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-42060.rs:13:16 | LL |     let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant |                ^^^^^^^^^^^^^ reserved keyword error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-42060.rs:19:6 | LL |     <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant |      ^^^^^^^^^ reserved keyword error: aborting due to 4 previous errors Some errors occurred: E0435, E0516. For more information about an error, try `rustc --explain E0435`. </ins>

Discussion:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.
Change:
); } } <del> initial_binding.res() </del> <ins> initial_binding </ins> }); let res = binding.res(); <del> if let Ok(initial_res) = initial_res { </del> <ins> if let Ok(initial_binding) = initial_binding { let initial_res = initial_binding.res(); </ins> if res != initial_res && this.ambiguity_errors.is_empty() { <del> span_bug!(import.span, "inconsistent resolution for an import"); </del> <ins> this.ambiguity_errors.push(AmbiguityError { kind: AmbiguityKind::Import, ident, b1: initial_binding, b2: binding, misc1: AmbiguityErrorMisc::None, misc2: AmbiguityErrorMisc::None, }); </ins> } } else if res != Res::Err && this.ambiguity_errors.is_empty()

Discussion:
thread 'rustc' panicked at ': inconsistent resolution for an import', <details<summaryBacktrace</summary</detailsRegression in nightly-2018-12-30 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same error message as , but this one is self-contained and might be a separate bug.
claim
how about make this to an error with diagonostic? Seems we don't have a chance to insert , because the is before the later . If we change code to this: It will be:
Could we register an exactly in the place we ICE?
Yes, this is also a solution, and then we can report error in the same function .
Change:
<ins> trait Fallback { fn foo(&self) {} } impl Fallback for i32 {} impl Fallback for u64 {} impl Fallback for usize {} fn main() { missing(); //~^ ERROR cannot find function `missing` in this scope 0.foo(); // But then we shouldn't report an inference ambiguity here... } </ins>

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
<ins> trait BufferMut {} struct Ctx<D>(D); trait BufferUdpStateContext<B> {} impl<B: BufferMut, C> BufferUdpStateContext<B> for C {} trait StackContext where Ctx<()>: for<'a> BufferUdpStateContext<&'a ()>, { type Dispatcher; } trait TimerContext { type Handler; } impl<C> TimerContext for C where C: StackContext, //~^ ERROR: is not satisfied [E0277] { type Handler = Ctx<C::Dispatcher>; //~^ ERROR: is not satisfied [E0277] } struct EthernetWorker<C>(C) where Ctx<()>: for<'a> BufferUdpStateContext<&'a ()>; impl<C> EthernetWorker<C> {} //~^ ERROR: is not satisfied [E0277] fn main() {} </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. --The code in question is from in Fuchsia. In order to reproduce, first and then . Once that's done, perform the following steps from inside the Fuchsia repository: <!-- 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. --Version from error output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Easy fix here. I saw this at one point in , but it went away with in the final version of that PR, so I had assumed that as the code evolved, this wouldn't get hit. Anyways, to fix, just make the arm be .
claim
Any way we can get an MCVE for this? Seems like an important test case for normalization under binders. ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
does that mean this is a stable-to-beta regression? If so, could you add that label (and the 1.56 milestone) to this issue so we can track it better?
good question, I don't know. If this indeed is directly caused by , then it would be, yes. Can somebody check this? I don't personally have the time to right now.
I would have no idea how to do that for the change that caused the issue. I was deep in the middle of tearing my hair out trying to figure out why a certain trait (in a very hairy mess of traits) wasn't implemented. I was confused enough as it was without the ICE MCVE would be great, but I unfortunately can't provide one starting from the offending change. Perhaps someone else can create a snippet tabula rasa based on where the ICE occurred?

This is a terrible MCVE, but it works and panics with two ICE: After fiddling a bit more with this, the culprit is indeed that is not implemented for .
wow! You rock!
Wow, fantastic work, !
This is fixed on nightly, just needs a test () in
claim
Change:
// gdb-command:print *owned // gdb-check:$5 = 6 <ins> // gdb-command:continue // gdb-command:print variable // gdb-check:$6 = 2 // gdb-command:print constant // gdb-check:$7 = 2 // gdb-command:print a_struct // gdb-check:$8 = {a = -3, b = 4.5, c = 5} // gdb-command:print *struct_ref // gdb-check:$9 = {a = -3, b = 4.5, c = 5} // gdb-command:print *owned // gdb-check:$10 = 6 </ins> // === LLDB TESTS ==================================================================================

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder