jiebi/CodeConvo huggingface dataset:
Change:
let bound_predicate = predicate.bound_atom(); match bound_predicate.skip_binder() { ty::PredicateAtom::Trait(p, _) => { <del> if self.is_param_no_infer(p.trait_ref.substs) && !only_projections && is_new_pred { self.add_user_pred(computed_preds, predicate); } </del> <ins> // Add this to `predicates` so that we end up calling `select` // with it. If this predicate ends up being unimplemented, // then `evaluate_predicates` will handle adding it the `ParamEnv` // if possible. </ins> predicates.push_back(bound_predicate.rebind(p)); } ty::PredicateAtom::Projection(p) => {

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. --This bug occurs with . works fine. <!-- 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
might be a duplicate of
I think there are important differences: this code doesn't use feature gates, and it successfully builds, so rustdoc should be expected to succeed instead of erroring or ICE, and the rationale for prioritizing that low (that the input is invalid) doesn't apply.
MCVE (although it panics in a slightly different place):
Oh interesting my MCVE is not correct - that panics because the impls are missing: If I add those impls, suddenly rustdoc works:
In fact there are some programs rustdoc accepts that rustc doesn't:
Slightly smaller repro:
Change:
|                     ^ not allowed in type signatures error[E0121]: the type placeholder `_` is not allowed within types on item signatures <ins> --> $DIR/typeck_type_placeholder_item.rs:216:31 | LL | fn value() -> Option<&'static _> { |               ----------------^- |               |               | |               |               not allowed in type signatures |               help: replace with the correct return type: `Option<&'static u8>` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/typeck_type_placeholder_item.rs:221:10 | LL | const _: Option<_> = map(value); |          ^^^^^^^^^ |          | |          not allowed in type signatures |          help: replace `_` with the correct type: `Option<u8>` error[E0121]: the type placeholder `_` is not allowed within types on item signatures </ins> --> $DIR/typeck_type_placeholder_item.rs:140:31 | LL |     fn method_test1(&self, x: _);

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
//! assert_eq!(s.find("you"), Some(4)); //! // char pattern //! assert_eq!(s.find('n'), Some(2)); <ins> //! // array of chars pattern //! assert_eq!(s.find(&['a', 'e', 'i', 'o', 'u']), Some(1)); </ins> //! // slice of chars pattern //! assert_eq!(s.find(&['a', 'e', 'i', 'o', 'u'][..]), Some(1)); //! // closure pattern

Discussion:
Many methods accept patterns of any type that implements the trait. One such type is , which matches any single character mentioned in the pattern slice. However, patterns are not as nice to use as one might hope. This does not compile: Rust complains: The method constrains its argument type with , and Rust won't apply the usual type coercions like to in order to satisfy trait bounds. One must instead write: It's not a tragedy, but it's not pretty either. CC
Shorter version:
cc
Lovely! This hadn't occurred to me.
Yeah, this was a known issue from the start. This concrete impl is basically a originally-nice API that is old enough that it got gradually worse over time in multiple iterations. If I remember right, there was originally a hardcoded method that just took a , and the language still allowed array literals to coerce to static slices, so originally you could do . At some point we got a cleaning up of the expression syntax, which lead to . And then when I proposed the trait the methods got generic, and no longer liked to do deref coercions, leading to the ugly as shortest possible literal form. I think the only real "fix" for this is deprecating this pattern, and/or holding out till we have char array generics and can have a impl for all directly.
Triage: Seems like the same status today; we are making progress on const generics, but it's not ready yet.
Change:
} /// Order `a` and `b` lexicographically using `TotalOrd` <del> pub fn cmp<A: TotalOrd, T: Iterator<A>>(mut a: T, mut b: T) -> cmp::Ordering { </del> <ins> pub fn cmp<A: TotalOrd, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> cmp::Ordering { </ins> loop { match (a.next(), b.next()) { (None, None) => return cmp::Equal,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
"exclusive range pattern syntax is experimental" ); gate_all_legacy_dont_use!(try_blocks, "`try` blocks are unstable"); <ins> gate_all_legacy_dont_use!(auto_traits, "`auto` traits are unstable"); </ins> visit::walk_crate(&mut visitor, krate); }

Discussion:
The following code builds on stable without even a warning: That is surprising since there was some effort recently to start ensuring that unstable syntax does not "leak" into stable Rust, so I expected at least a future-compatibility warning. (See e.g. ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
from the code I'd expect a warning:
ah no, auto traits don't use that gating: When parsing an auto trait in the parser, we need to gate it's span and then in the feature gating pass gate it too. This will look similar to, for example, traitalias.
was just for syntax which was previously attempted to reverse stabilization and had the gating code there but disabled. Now that the plumbing exists, using that as a template to add this syntax to the warning should be fairly straightforward. It might make sense to go ahead and crater immediately making this a hard feature gate, though.
I can already tell you of one large regression, the . We should do the feature gating normally as a warning and worry about making it an error later. Once it's a warning, people adding uses get warnings and we should be fine.
A bit unrelated, but I think it would be useful to have docs somewhere that show how to resolve this issue if you have the feature behind a cfg, the easiest solution being a macro_rules macro. But that doesn't have to be fixed here.
Change:
fn check_pat_path( &self, pat: &hir::Pat, <ins> path_resolution: (Res, Option<Ty<'tcx>>, &'b [hir::PathSegment]), </ins> qpath: &hir::QPath, expected: Ty<'tcx>, ) -> Ty<'tcx> { let tcx = self.tcx; <del> // Resolve the path and check the definition for errors. let (res, opt_ty, segments) = self.resolve_ty_and_res_ufcs(qpath, pat.hir_id, pat.span); </del> <ins> // We have already resolved the path. let (res, opt_ty, segments) = path_resolution; </ins> match res { Res::Err => { self.set_tainted_by_errors();

Discussion:
The following, which I expect to work, fails to infer the type of : In HIR, should correspond to: However, if we change the snippet to: it all works out fine. I also tested changing to a tuple variant and that works also. cc cc
It might be a good idea to trace the difference between and because they look relatively similar and yet they behave differently in terms of inference.
Value (/) and type () namespaces execute very different logic for type inference (/ vs ). It's quite possible that there are intended and unintended observable differences (not necessarily specific to ). checkpatpath and checkpattuplestruct Rather and . ( is the same "value" case as .)
Change:
# - set PATH=%PATH%;%CD% -- this already happens above for sccache # Install InnoSetup to get `iscc` used to produce installers <del> - appveyor-retry choco install -y InnoSetup </del> <ins> - appveyor-retry appveyor DownloadFile https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-08-22-is.exe - 2017-08-22-is.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- </ins> - set PATH="C:Program Files (x86)Inno Setup 5";%PATH% # Help debug some handle issues on AppVeyor

Discussion:
Contains messages like Possible cause:
Seems no longer happen. Will close once all linked PRs are merged.
IIRC this isn't the first time this has happened. We should probably just mirror whatever we need locally in our S3 mirror. If someone's willing to figure out how to change the build to not hit but hit a custom download, I'd be more than willing to upload some artifacts!
Change:
// Only for re-exporting: #![feature(assert_matches)] #![feature(async_iterator)] <del> #![feature(c_size_t)] </del> #![feature(c_variadic)] #![feature(cfg_accessible)] #![feature(cfg_eval)]

Discussion:
https://crater- https://crater- https://crater- https://crater- Introduced by , most likely, cc
One reasonable fix is to stabilize these types in . That will allow using reexports instead of type aliases, which will remove the ambiguities. They are the same types as stable types in just exposed from a different (but also stable) location in the same crate. (That said, glob vs glob is an acceptable breakage according to the library policy.)
That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable.
If we were to stabilize, presumably we'd do that on master and back out the PR from beta? I am reluctant to backport a stabilization to fix this (particularly a fast one, as you mention).
Yeah, reverting the PR on beta seems fine for now.
Change:
<ins> // edition:2015 // check-pass // issue: 114664 fn ice() -> impl AsRef<Fn(&())> { //~^ WARN trait objects without an explicit `dyn` are deprecated //~| WARN trait objects without an explicit `dyn` are deprecated //~| WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! Foo } struct Foo; impl AsRef<dyn Fn(&())> for Foo { fn as_ref(&self) -> &(dyn for<'a> Fn(&'a ()) + 'static) { todo!() } } pub 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
This is not an RPITIT bug, for the record.
Change:
<ins> // check-pass // dont-check-compiler-stdout // compile-flags: -Z unpretty=mir-cfg // This checks that unpretty=mir-cfg does not panic. See #81918. const TAG: &'static str = "ABCD"; fn main() { if TAG == "" {} } </ins>

Discussion:
The working example in builds fine, but if I add it panics. Repro: It builds fine: Panics with : <details<summaryBacktrace</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the panic was by you. Could you say a few words on what the issue here? I'd be happy to investigate further and fix, but I have no idea where to start.
That's an oversight by me. In you instead need to do something similar to mir printing. That is, use instead of , but also create a second dump for by additionally using to show the graph of the ctfe version of the const fn
is somewhat related, as we should probably first fix that one and then deduplicate the mir selection logic between cfg printing and regular mir dumps.
has a smaller repro.
claim
Change:
| LL | fn foo<T: Into<String>>(x: i32) {} |           ^^^^^^^^^^^^ required by this bound in `foo` <del> help: consider specifying the generic argument | LL |     foo::<T>(42); |        +++++ </del> help: consider specifying the type argument in the function call | LL |     foo::<T>(42);

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
body: &'a Body<'tcx>, env: &'a MoveDataParamEnv<'tcx>, init_data: InitializationData<'a, 'tcx>, <del> drop_flags: FxHashMap<MovePathIndex, Local>, </del> <ins> drop_flags: IndexVec<MovePathIndex, Option<Local>>, </ins> patch: MirPatch<'tcx>, un_derefer: UnDerefer<'tcx>, reachable: BitSet<BasicBlock>,

Discussion:
This code creates MIR statements based on an iteration order: is defined as: Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect). We should probably sort by before creating the statements.
Perhaps it should just use instead?
Revisiting this issue to evaluate the priority. unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on . Unsure if it helps and - if yes - how much does that pull request covers to fix this issue. opinions? thanks :)
Change:
Some(def_id) }); <del> tcx.arena.alloc_from_iter(own_entries.into_iter()) </del> <ins> own_entries </ins> } /// Given a trait `trait_ref`, iterates the vtable entries

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
<ins> error[E0277]: the trait bound `B: Clone` is not satisfied --> $DIR/issue-79224.rs:18:17 | LL | impl<B: ?Sized> Display for Cow<'_, B> { |                 ^^^^^^^ the trait `Clone` is not implemented for `B` | = note: required because of the requirements on the impl of `ToOwned` for `B` help: consider further restricting this bound | LL | impl<B: ?Sized + std::clone::Clone> Display for Cow<'_, B> { |                +++++++++++++++++++ error[E0277]: the trait bound `B: Clone` is not satisfied --> $DIR/issue-79224.rs:19:5 | LL | /     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { LL | |         write!(f, "foo") LL | |     } | |_____^ the trait `Clone` is not implemented for `B` | = note: required because of the requirements on the impl of `ToOwned` for `B` help: consider further restricting this bound | LL | impl<B: ?Sized + std::clone::Clone> Display for Cow<'_, B> { |                +++++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </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. --I wanted to change to use the pattern in the code below (which changes variance w.r.t to ), but got an ICE. I managed to reduce it the code below. The same code with the current definition of works (same as ): <!-- 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<details<summary<stronglog with RUSTCLOG=rustctrait_selection::traits::specialize</strong</summary<p</p</details
This ICEs since modify labels: +regression-from-stable-to-stable
Assigning as discussed as part of the and removing .
No longer appears to ICE since
Change:
use crate::traits::query::evaluate_obligation::InferCtxtExt as _; <del> use crate::traits::{self, ObligationCtxt}; </del> <ins> use crate::traits::{self, DefiningAnchor, ObligationCtxt}; </ins> use rustc_hir::def_id::DefId; use rustc_hir::lang_items::LangItem;

Discussion:
This used to compile and now ICEs: Compiles on Stable version: 1.70.0 Regressed in 1.71.0-beta.6 (2023-07-08 ) I guess it is , but this shouldn't be in beta? <details<summary<strongBacktrace</strong</summary<p</p</details
Bisection results: searched nightlies: from nightly-2023-05-20 to nightly-2023-07-14 regressed nightly: nightly-2023-06-25 searched commit range: regressed commit: ( -), cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
f: impl FnOnce(&mut Self) -> (&'hir [hir::Param<'hir>], hir::Expr<'hir>), ) -> hir::BodyId { let prev_gen_kind = self.generator_kind.take(); <ins> let task_context = self.task_context.take(); </ins> let (parameters, result) = f(self); let body_id = self.record_body(parameters, result); <ins> self.task_context = task_context; </ins> self.generator_kind = prev_gen_kind; body_id }

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-22 searched commits: from to regressed commit:
Simplified: and cc ()
Fix up at
Change:
LL |         Dog { age: x, .. } => {} |                     ^^^^ <ins> error[E0027]: pattern does not mention field `age` --> $DIR/E0027.rs:15:9 | LL |         Dog { name: x, } => {} |         ^^^^^^^^^^^^^^^^ missing field `age` | help: include the missing field in the pattern | LL |         Dog { name: x, age } => {} |                      ^^^^^ help: if you don't care about this missing field, you can explicitly ignore it | LL |         Dog { name: x, .. } => {} |                      ^^^^ error[E0027]: pattern does not mention field `age` --> $DIR/E0027.rs:19:9 | LL |         Dog { name: x  , } => {} |         ^^^^^^^^^^^^^^^^^^ missing field `age` | help: include the missing field in the pattern | LL |         Dog { name: x, age } => {} |                      ^^^^^ help: if you don't care about this missing field, you can explicitly ignore it | LL |         Dog { name: x, .. } => {} |                      ^^^^ </ins> error[E0027]: pattern does not mention fields `name`, `age` <del> --> $DIR/E0027.rs:13:9 </del> <ins> --> $DIR/E0027.rs:22:9 </ins> | LL |         Dog {} => {} |         ^^^^^^ missing fields `name`, `age`

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics
Change:
<ins> // compile-flags: --crate-type=lib -Zmir-opt-level=2 // build-pass // ^-- Must be build-pass, because check-pass will not run const prop. pub trait TestTrait { type MyType; fn func() -> Option<Self> where Self: Sized; } impl<T> dyn TestTrait<MyType = T> where Self: Sized, { pub fn other_func() -> Option<Self> { match Self::func() { Some(me) => Some(me), None => None, } } } </ins>

Discussion:
This only happens when compiled in a library, not an executable. The associated type , both of the 's, the (instead of just ), and the match statement are all needed to make it panic. Replacing the match statement with errors gracefully, and says that I cannot call unwrap on a trait object; so I assume the error that should have been emitted for the match statement is that I cannot destructure a trait object. Replacing the match with compiles successfully. This happens on stable, nightly, and beta. : <details<summary<strongBacktrace</strong</summary<p</p</details
also happens on nightly
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
This ICE still exists, but the "internal compiler error" and "query stack during panic" sections of the error output have changed on 1.58.0-nightly. I'm running this on a different machine than the one I initially posted the issue from. The output in 1.56.1-stable is still the same as it was when I originally posted the issue. <details<summary<strongBacktrace</strong</summary<p</p</details
Additionally, the new ICE now happens when the code is compiled into an executable, but only on nightly. This didn't happen before. On 1.56.1-stable in , the compiler emits a warning that is never used, and compiles successfully. Edit: the error now happens on 1.60.0 stable when compiling in a binary as well.
Triage: the issue has been fixed on the latest nightly, marking as .
Change:
<ins> #![feature(const_generics)] pub struct Struct<const N: usize>(pub [u8; N]); pub type Alias = Struct<2>; pub fn function(value: Struct<3>) -> u8 { value.0[0] } </ins>

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.