jiebi/CodeConvo huggingface dataset:
Change:
for &(ref tree, id) in items { self.build_reduced_graph_for_use_tree( // This particular use tree <del> tree, id, &prefix, true, // The whole `use` item </del> <ins> tree, id, &prefix, true, false, // The whole `use` item </ins> item, vis, root_span, ); }

Discussion:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!
Change:
} } <del> let discr = Scalar { </del> <ins> let tag_mask = !0u128 >> (128 - ity.size().bits()); let tag = Scalar { </ins> value: Int(ity, signed), <del> valid_range: (min as u128)..=(max as u128) </del> <ins> valid_range: (min as u128 & tag_mask)..=(max as u128 & tag_mask), </ins> }; <del> let abi = if discr.value.size(dl) == size { Abi::Scalar(discr.clone()) </del> <ins> let abi = if tag.value.size(dl) == size { Abi::Scalar(tag.clone()) </ins> } else { Abi::Aggregate { sized: true } }; tcx.intern_layout(LayoutDetails { variants: Variants::Tagged { <del> discr, </del> <ins> discr: tag, </ins> variants }, fields: FieldPlacement::Arbitrary {

Discussion:
Rust 1.23.0 correctly prints . Rust 1.24.0 incorrectly prints . Mentioning because this sounds potentially relevant to or follow-on optimization. (Discovered by in #rust.)
Clearly from rather than a followup, as it's happening in nightly-2017-11-21 and not in nightly-2017-11-20.
This is not specific to but to the enum using both signed extremums of its representation type:
Change:
fallback_has_occurred: bool, mutate_fullfillment_errors: impl Fn(&mut Vec<traits::FulfillmentError<'tcx>>), ) { <del> if let Err(mut errors) = self.fulfillment_cx.borrow_mut().select_where_possible(self) { </del> <ins> let result = self.fulfillment_cx.borrow_mut().select_where_possible(self); if let Err(mut errors) = result { </ins> mutate_fullfillment_errors(&mut errors); self.report_fulfillment_errors(&errors, self.inh.body_id, fallback_has_occurred); }

Discussion:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.
Change:
trace!("local {:?} can't be propagated because it's used: {:?}", local, context); self.can_const_prop[local] = ConstPropMode::NoPropagation; } <ins> MutatingUse(MutatingUseContext::Projection) | NonMutatingUse(NonMutatingUseContext::Projection) => bug!("visit_place should not pass {context:?} for {local:?}"), </ins> } } }

Discussion:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with
Change:
} match parse_item(self) { Ok(None) => { <del> let is_unnecessary_semicolon = !items.is_empty() </del> <ins> let mut is_unnecessary_semicolon = !items.is_empty() </ins> // When the close delim is `)` in a case like the following, `token.kind` is expected to be `token::CloseDelim(Delimiter::Parenthesis)`, <del> // but the actual `token.kind` is `token::CloseDelim(Delimiter::Bracket)`. </del> <ins> // but the actual `token.kind` is `token::CloseDelim(Delimiter::Brace)`. </ins> // This is because the `token.kind` of the close delim is treated as the same as // that of the open delim in `TokenTreesReader::parse_token_tree`, even if the delimiters of them are different. // Therefore, `token.kind` should not be compared here.

Discussion:
When copying bounds from a trait assoc item, you can accidentally copy the semicolon. If you forget to remove it, multiple errors are emitted, while the second is: This should be explicitly handled to avoid knock down errors. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let mut x = Int(0); x += 1; //~^ error: overloaded augmented assignments are not stable <del> // | help: add #![feature(augmented_assignments)] to the crate features to enable </del> <ins> // | help: add #![feature(augmented_assignments)] to the crate root to enable </ins> }

Discussion:
I the augmented_assignments feature to the , but when testing, the compiler complained: I thought I had already done that, but it turns out it isn't enough to be in the source file using the feature. In retrospect (now that I know from help on IRC what the issue is), I'd expect the error to say: or something to that effect.
Change:
<ins> error: concrete type differs from previous defining opaque type use --> $DIR/recursive-tait-conflicting-defn-2.rs:12:5 | LL |     transform::<Op>() |     ^^^^^^^^^^^^^^^^^ expected `&'static &'static str`, got `impl std::fmt::Display` | note: previous use here --> $DIR/recursive-tait-conflicting-defn-2.rs:6:18 | LL | fn foo() -> Op { &"hello world" } |                  ^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

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 tried this code: I expected to see this happen: compile error that said the return type is wrong. Instead, this happened: compiled without error <!-- 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. --:
cc

edit: minimized see for more details <!-- 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 tried this code: I expected to see this happen: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as
Change:
[dependencies] # tidy-alphabetical-start bitflags = "2.4.1" <del> pulldown-cmark = { version = "0.9.3", default-features = false } </del> <ins> pulldown-cmark = { version = "0.9.6", default-features = false } </ins> rustc_arena = { path = "../rustc_arena" } rustc_ast = { path = "../rustc_ast" } rustc_ast_pretty = { path = "../rustc_ast_pretty" }

Discussion:
Footnote lines, when written on adjacent lines, squish into a single footnote: ! -paste the following snippet at the top of a new module: . that the footnotes have been incorrectly rendered as a single footnote. No response One workaround is to separate the footnotes with empty lines: It's not pretty, though.
Transferring to Rust as it is an issue with doc generation.
I think this is somewhat working as intended. Footnote definitions need to be separated by blank lines. That is not ideal, and I think is the closest thing tracking this issue.
This is the expected behaviour from commonmark as you can see . Closing then.
Hi CommonMark does not support footnotes at all. RustDoc is very explicit that it does, so the behaviour of RustDoc's footnotes should probably be based on whatever library it uses for Markdown parsing rather than actual CommonMark. You can see from this simple example that : But :
Oh I see, my apologies. Reopening the issue then.
Triage: Still an issue.
Taking a look.
Change:
# This is intended to make sure that both `--pass=check` continues to # work. # <del> python2.7 ../x.py --stage 2 test src/test/ui --pass=check --target=i686-unknown-linux-gnu &&  </del> <ins> python2.7 ../x.py --stage 2 test src/test/ui --pass=check  --host='' --target=i686-unknown-linux-gnu &&  </ins> # Run tidy at the very end, after all the other tests. python2.7 ../x.py --stage 2 test src/tools/tidy

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.
Change:
use rustc_hir::def::{CtorOf, Res}; use rustc_hir::def_id::LocalDefId; use rustc_hir::{HirId, PatKind}; <del> use rustc_middle::{bug, span_bug}; </del> use rustc_middle::hir::place::ProjectionKind; use rustc_middle::mir::FakeReadCause; use rustc_middle::ty::{ self, adjustment, AdtKind, Ty, TyCtxt, TypeFoldable, TypeVisitableExt as _, }; <ins> use rustc_middle::{bug, span_bug}; </ins> use rustc_span::{ErrorGuaranteed, Span}; use rustc_target::abi::{FieldIdx, VariantIdx, FIRST_VARIANT}; use rustc_trait_selection::infer::InferCtxtExt;

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim
Change:
self_ty: Ty<'tcx>, scope_expr_id: HirId, scope: ProbeScope, <del> ) -> Vec<Candidate<'tcx>> { </del> <ins> ) -> Result<Vec<Candidate<'tcx>>, MethodError<'tcx>> { </ins> self.probe_op( item_name.span, mode,

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
Change:
<ins> error[E0599]: no associated item named `LINKS` found for type parameter `A` in the current scope --> $DIR/associated-item-duplicate-bounds.rs:7:21 | LL |     links: [u32; A::LINKS], // Shouldn't suggest bounds already there. |                     ^^^^^ associated item not found in `A` | = help: items from traits can only be used if the type parameter is bounded by the trait error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Given the following test and nightly 2020-01-12: I get that this is not supposed to work without const generics, but the error message suggestion is very funny: With const generics:
Weird suggestion is on current stable as well.
The ICE component is fixed by , the diagnostics issue remains ()
I think it's another example of now.
Change:
default_impl! { i64, 0, "Returns the default value of `0`" } default_impl! { i128, 0, "Returns the default value of `0`" } <ins> #[cfg(not(bootstrap))] default_impl! { f16, 0.0f16, "Returns the default value of `0.0`" } </ins> default_impl! { f32, 0.0f32, "Returns the default value of `0.0`" } default_impl! { f64, 0.0f64, "Returns the default value of `0.0`" } <ins> #[cfg(not(bootstrap))] default_impl! { f128, 0.0f128, "Returns the default value of `0.0`" } </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. --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:
.arg(host); build.run(&mut cmd); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust-MinGW") .arg("--rel-manifest-dir=rustlib")

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
<ins> // build-pass // edition:2018 static A: [i32; 5] = [1, 2, 3, 4, 5]; async fn fun() { let u = A[async { 1 }.await]; match A { i if async { true }.await => (), _ => (), } } fn main() { async { let u = A[async { 1 }.await]; }; async { match A { i if async { true }.await => (), _ => (), } }; } </ins>

Discussion:
I have some code which asynchronously computes an integer, and selects an item from a static slice in the same expression. This used to work (it does on stable), but after a nightly update the compiler ICEs when computing generator layout. The bug stops reproducing if I change the static to a local variable, or extract the index into a separate variable. rustc 1.41.0-nightly ( 2019-11-23) binary: rustc commit-hash: commit-date: 2019-11-23 host: x86_64-unknown-linux-gnu release: 1.41.0-nightly LLVM version: 9.0
De-nominating from compiler team as we have a fix pending.
triage: P-high.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(const_fn)] struct A { field: usize, } const fn f() -> usize { 5 } fn main() { let _ = [0; f()]; } </ins>

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in
Change:
) } <del> /// Transform a `PolyTraitRef` into a `PolyExistentialTraitRef` by /// removing the dummy `Self` type (`trait_object_dummy_self`). fn trait_ref_to_existential(&self, trait_ref: ty::TraitRef<'tcx>) -> ty::ExistentialTraitRef<'tcx> { if trait_ref.self_ty() != self.tcx().types.trait_object_dummy_self { bug!("trait_ref_to_existential called on {:?} with non-dummy Self", trait_ref); } ty::ExistentialTraitRef::erase_self_ty(self.tcx(), trait_ref) } </del> fn conv_object_ty_poly_trait_ref(&self, span: Span, trait_bounds: &[hir::PolyTraitRef],

Discussion:
The following code panics the compiler:
backtrace: <details</details
~Likely diagnostic related :-/~ Disregard that.
Slightly reduced: can also be , but I though this will remove one more warning, so it's worth using here ^^
triage: P-medium. removing nomination label. reasoning: you get the feature flag diagnostic, including the span of the offending code and the suggestion of what to write. So this is reasonable for users to deal with, even with the ICE. (as opposed to cases where the ICE occurs without any useful output for the user.)
Change:
/// ``` #[lang = "index"] #[rustc_on_unimplemented( <ins> on( _Self="&str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="std::string::String", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), </ins> message="the type `{Self}` cannot be indexed by `{Idx}`", label="`{Self}` cannot be indexed by `{Idx}`", )]

Discussion:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :