jiebi/CodeConvo huggingface dataset:
Change:
<del> //@ known-bug: #121613 fn main() { let _ = <Foo as A>::Assoc { br: 2 }; let <E>::V(..) = E::V(|a, b| a.cmp(b)); } struct StructStruct { br: i8, } struct Foo; trait A { type Assoc; } impl A for Foo { type Assoc = StructStruct; } enum E { V(u8), } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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 --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!
Change:
| = help: the trait `PartialEq<Result<{integer}, _>>` is not implemented for `{integer}` = help: the following other types implement trait `PartialEq<Rhs>`: <ins> f128 f16 </ins> f32 f64 i128 i16 i32 i64 <del> i8 isize and 6 others </del> <ins> and 8 others </ins> error: aborting due to 6 previous errors

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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.
Change:
<ins> error[E0277]: the trait bound `f64: Eq` is not satisfied --> $DIR/issue-103157.rs:6:11 | LL | #[derive(PartialEq, Eq)] |                     -- in this derive macro expansion ... LL |     Float(Option<f64>), |           ^^^^^^^^^^^ the trait `Eq` is not implemented for `f64` | = help: the following other types implement trait `Eq`: i128 i16 i32 i64 i8 isize u128 u16 and 4 others = note: required for `Option<f64>` to implement `Eq` note: required by a bound in `AssertParamIsEq` --> $SRC_DIR/core/src/cmp.rs:LL:COL | LL | pub struct AssertParamIsEq<T: Eq + ?Sized> { |                               ^^ required by this bound in `AssertParamIsEq` = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
#[link(name = "llvm-wrapper", kind = "static")] extern "C" { <del> pub fn LLVMRustInstallFatalErrorHandler(); </del> <ins> pub fn LLVMRustInstallErrorHandlers(); </ins> pub fn LLVMRustDisableSystemDialogsOnCrash(); // Create and destroy contexts.

Discussion:
Running a build of , as part of a Koiji (Fedora Build System) job, I get the following for the target: Also see:
To my understanding this should be Rust
I think this is "just" an OOM situation. Fedora builds with full debuginfo by default, and this package is configured for fat LTO as well, which will all get quite heavy. When I tried to reproduce this with the stable toolchain, I got: It completed when I turned off debuginfo though. With Fedora's toolchain, I can reproduce your SIGSEGV in LLVM, but it also completes the build when debuginfo is off. My guess is that it is also hitting an allocation failure, but perhaps in a place that doesn't properly check the pointer before trying to use it.
With the rustup toolchain, it's running out of memory in LLVM's , which calls allocation methods that abort on failure. That's where we get the "LLVM ERROR: out of memory", "Allocation failed". With the Fedora toolchain, it's running out of memory in LLVM's , which calls to plain , throwing . Rust runs its own destructors during that unwind, in particular dropping that calls , and this segfaults in a (presumably the same one).
I encontered this when compiling a big proprietary project to --target=i686-unknown-linux-musl using nightly-2024-03-01 on a x86_64 host
with an x86_64 host and a different backtrace, I doubt that yours has the same root cause. I suggest filing a separate issue -- but it's going to be hard for anyone to help if they can't reproduce it, since your code is proprietary.
Change:
_ => check_operand(tcx, mir, operand, span), } } <ins> Rvalue::Cast(CastKind::UnsafeFnPointer, _, _) | Rvalue::Cast(CastKind::ClosureFnPointer, _, _) | Rvalue::Cast(CastKind::ReifyFnPointer, _, _) => Err(( span, "function pointer casts are not allowed in const fn".into(), )), Rvalue::Cast(CastKind::Unsize, _, _) => Err(( span, "unsizing casts are not allowed in const fn".into(), )), </ins> // binops are fine on integers Rvalue::BinaryOp(_, lhs, rhs) | Rvalue::CheckedBinaryOp(_, lhs, rhs) => { check_operand(tcx, mir, lhs, span)?;

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
| |_____^ error[E0572]: return statement outside of function body <del> --> $DIR/issue-86188-return-not-in-fn-body.rs:17:10 </del> <ins> --> $DIR/issue-86188-return-not-in-fn-body.rs:20:14 | LL | /     fn bar() { LL | | LL | |         [(); return]; | |              ^^^^^^ the return is part of this body... LL | | LL | | LL | |     } | |_____- ...not the enclosing function body error[E0572]: return statement outside of function body --> $DIR/issue-86188-return-not-in-fn-body.rs:28:14 | LL | /     fn foo() { LL | | LL | |         [(); return]; | |              ^^^^^^ the return is part of this body... LL | | LL | | LL | |     } | |_____- ...not the enclosing function body error[E0572]: return statement outside of function body --> $DIR/issue-86188-return-not-in-fn-body.rs:36:10 </ins> | LL |  / fn main() { LL |  |

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
$(CFG_PANDOC) $(HTML_OPTS) --include-in-header=doc/full-toc.inc --output=$@ DOCS += doc/rust.tex <del> doc/rust.tex: $(D)/rust.md doc/version.md | doc/ </del> <ins> doc/rust.tex: $(D)/rust.md doc/footer.tex doc/version.md | doc/ </ins> @$(call E, pandoc: $@) $(Q)$(CFG_NODE) $(D)/prep.js $< |  $(CFG_PANDOC) $(TEX_OPTS) --output=$@

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.
Change:
pub(super) buf: NonNull<T>, pub(super) phantom: PhantomData<T>, pub(super) cap: usize, <del> pub(super) alloc: A, </del> <ins> // the drop impl reconstructs a RawVec from buf, cap and alloc // to avoid dropping the allocator twice we need to wrap it into ManuallyDrop pub(super) alloc: ManuallyDrop<A>, </ins> pub(super) ptr: *const T, pub(super) end: *const T, }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
tracing = "0.1" jobserver_crate = { version = "0.1.13", package = "jobserver" } lazy_static = "1" <del> once_cell = { version = "1", features = ["parking_lot"] } </del> rustc_serialize = { path = "../rustc_serialize" } rustc_macros = { path = "../rustc_macros" } rustc_graphviz = { path = "../rustc_graphviz" }

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
<del> error[E0107]: function takes 2 generic arguments but 1 generic argument was supplied --> $DIR/foreign-generic-mismatch-with-const-arg.rs:6:46 | LL |     foreign_generic_mismatch_with_const_arg::test::<1>(); |                                              ^^^^   - supplied 1 generic argument |                                              | |                                              expected 2 generic arguments | note: function defined here, with 2 generic parameters: `N`, `T` --> $DIR/auxiliary/foreign-generic-mismatch-with-const-arg.rs:1:8 | LL | pub fn test<const N: usize, T>() {} |        ^^^^ --------------  - help: add missing generic argument | LL |     foreign_generic_mismatch_with_const_arg::test::<1, T>(); |                                                      +++ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </del>

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. --cc still crashes after <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
trace!("encoding {:?} with {:#?}", alloc_id, fn_instance); FN_DISCRIMINANT.encode(encoder)?; fn_instance.encode(encoder)?; <ins> } else if let Some(did) = tcx.interpret_interner.get_corresponding_static_def_id(alloc_id) { // extern "C" statics don't have allocations, just encode its def_id EXTERN_STATIC_DISCRIMINANT.encode(encoder)?; did.encode(encoder)?; </ins> } else { bug!("alloc id without corresponding allocation: {}", alloc_id); }

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
<ins> error: unknown start of token: u{326} --> $DIR/incorrect-first-separator.rs:19:28 | LL |     format!("A number: {}" ̦ iter::once(42).next().unwrap()); |                            ^ error: expected token: `,` --> $DIR/incorrect-first-separator.rs:7:27 | LL |     format!("A number: {}". iter::once(42).next().unwrap()); |                           ^ expected `,` error: expected token: `,` --> $DIR/incorrect-first-separator.rs:12:28 | LL |     format!("A number: {}" / iter::once(42).next().unwrap()); |                            ^ expected `,` error: expected token: `,` --> $DIR/incorrect-first-separator.rs:15:27 | LL |     format!("A number: {}"; iter::once(42).next().unwrap()); |                           ^ expected `,` error: expected token: `,` --> $DIR/incorrect-first-separator.rs:19:30 | LL |     format!("A number: {}" ̦ iter::once(42).next().unwrap()); |                             ^^^^ expected `,` error: aborting due to 5 previous errors </ins>

Discussion:
says: ... which isn't exactly where the was expected. () Another variation is this code: which gives this result: ()
Hello, I am a quite new contributor, and I'd like to tackle this issue. Do you think that is possible? I have looked a bit at the code, and I think this mostly comes from the [] function, more precisely, [this condition][cond] can be tweaked. Is that correct? []: [cond]:
Turns out I was terribly wrong. The problem is that the following snippet: Can be rewritten as: And that the [] function looks for an expression as the first argument ([corresponding code][expression], [code example][snippet]). Consequently, is the said expression, which explain why the error is raised on the first . Now that I know where the error comes from. I think the best way to fix this issue is to check if this expression can be a format string, perhaps with the [] function. I am still unsure about the quality of the emitted error, but at least it would have the correct span. []: [expression]: [snippet]: []:
Change:
<del> error[E0277]: the size for values of type `dyn std::iter::Iterator<Item = &mut u8>` cannot be known at compilation time </del> <ins> error[E0277]: the size for values of type `dyn std::iter::Iterator<Item = &'a mut u8>` cannot be known at compilation time </ins> --> $DIR/issue-20605.rs:2:17 | LL |     for item in *things { *item = 0 } |                 ^^^^^^^ doesn't have a size known at compile-time | <del> = help: the trait `std::marker::Sized` is not implemented for `dyn std::iter::Iterator<Item = &mut u8>` </del> <ins> = help: the trait `std::marker::Sized` is not implemented for `dyn std::iter::Iterator<Item = &'a mut u8>` </ins> = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait> = note: required by `std::iter::IntoIterator::into_iter`

Discussion:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
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
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).
Change:
Res::Def(DefKind::Ctor(..), def_id) => { tcx.generics_of(tcx.parent(def_id).unwrap()) } <del> Res::Def(_, def_id) => tcx.generics_of(def_id), </del> <ins> // Other `DefKind`s don't have generics and would ICE when calling // `generics_of`. Res::Def( DefKind::Struct | DefKind::Union | DefKind::Enum | DefKind::Variant | DefKind::Trait | DefKind::OpaqueTy | DefKind::TyAlias | DefKind::ForeignTy | DefKind::TraitAlias | DefKind::AssocTy | DefKind::Fn | DefKind::AssocFn | DefKind::AssocConst | DefKind::Impl, def_id, ) => tcx.generics_of(def_id), </ins> Res::Err => { tcx.sess.delay_span_bug(tcx.def_span(def_id), "anon const with Res::Err"); return None;

Discussion:
Crashes when running . <!-- 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
Regression in nightly-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]: