jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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
Can be reduced to
Also causes the out of bounds panic (), but not the earlier type mismatch ICE
Triage: Fixed on the latest nightly, marked as E-needs-test labels: +E-needs-test

Related discussion:
text: <ins> error: concrete type differs from previous defining opaque type use --> $DIR/recursive-fn-tait.rs:14:5 | LL |     move |x: usize| m(n(x)) |     ^^^^^^^^^^^^^^^^^^^^^^^ expected `{closure@$DIR/recursive-fn-tait.rs:7:5: 7:16}`, got `{closure@$DIR/recursive-fn-tait.rs:14:5: 14:20}` | note: previous use here --> $DIR/recursive-fn-tait.rs:7:5 | LL |     |_: usize |loop {} |     ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with

Related discussion:
text: use rustc_middle::ty::{ self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, Ty, TypeFoldable, }; <del> use rustc_span::Span; </del> <ins> use rustc_span::{symbol::kw, Span}; </ins> use rustc_trait_selection::traits; use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt;
Code change:
When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with

Related discussion:
text: continue; } <ins> // HACK: `async fn() -> Self` in traits is "ok"... // This is not really that great, but it's similar to why the `-> Self` // return type is well-formed in traits even when `Self` isn't sized. if let ty::Param(param_ty) = *proj_term.kind() && param_ty.name == kw::SelfUpper && matches!(opaque.origin, hir::OpaqueTyOrigin::AsyncFn(_)) && opaque.in_trait { continue; } </ins> let proj_ty = Ty::new_projection(cx.tcx, proj.projection_ty.def_id, proj.projection_ty.args); // For every instance of the projection type in the bounds,
Code change:
When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with

Related discussion:
text: <ins> // check-pass // edition:2021 #![deny(opaque_hidden_inferred_bound)] trait Repository /* : ?Sized */ { async fn new() -> Self; } struct MyRepository {} impl Repository for MyRepository { async fn new() -> Self { todo!() } } fn main() {} </ins>
Code change:
This is a regression from
in general the fix for this is usually to add before the line so that they don't overlap
we might want to consider changing to bypass the type-based cache so it catches ordering bugs like this cc
I don't understand how dry run is relevant here, isn't this a problem in all cases? Dry run and real should have roughly the same ensure graph to the extent possible and our tests rely on that... It also seems like based on the linked PR here this assertion is always guaranteed to show up at runtime pretty much constantly anytime someone accidentally adds additional nesting with a group? I could see that the right fix is to track the group and end + restart it so that there's no nesting and instead a linear non-nested list of groups...
dry-run and real have the same problems, yes. my idea was to do extra checks in dry-run so that without arguments would have caught this - the reason it only gets triggered with the filter is because normally, an earlier Step will happen to call , so the dynamic GHA check never gets run. correct. i was hoping that the check was eager enough they'd notice immediately and fix it in order to make CI pass, but this issue shows that it's non-trivial to do so because of the way it depends on the cache. this is how dry-run gets involved - when it's enabled, bypassing the cache is cheap and we can just do it unconditionally, which would have caught this bug before it got merged. hmm, that might handle our current cases ok, but it's not correct in general - consider something like that will split up the single message before and after, which doesn't seem quite right, although i suppose it might be better than panicking?
Ah, I see. I'm not convinced that we'd not stop catching other problems and/or introduce them by changing dry run. The split example you suggest feels right to me - in some sense more right - it means we are putting things in finest granularity groups. It also matches what we do for metrics emission, I believe... I will say that I don't really understand the value in the grouping, so perhaps that would change my thinking there.... At minimum, we might consider not panicking outside of GHA workloads, since the grouping doesn't matter then?

Related discussion:
text: let mut tool = tool::ErrorIndex::command(builder); tool.arg("markdown").arg(&output); <del> let _guard = </del> <ins> let guard = </ins> builder.msg(Kind::Test, compiler.stage, "error-index", compiler.host, compiler.host); let _time = util::timeit(&builder); builder.run_quiet(&mut tool); <ins> drop(guard); </ins> // The tests themselves need to link to std, so make sure it is // available. builder.ensure(compile::Std::new(compiler, compiler.host));
Code change:
<!-- 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.

Related discussion:
text: use super::ResolverAstLoweringExt; use rustc_ast::visit::{self, BoundKind, LifetimeCtxt, Visitor}; use rustc_ast::{GenericBounds, Lifetime, NodeId, PathSegment, PolyTraitRef, Ty, TyKind}; <del> use rustc_hir::def::LifetimeRes; </del> <ins> use rustc_hir::def::{DefKind, LifetimeRes, Res}; </ins> use rustc_middle::span_bug; use rustc_middle::ty::ResolverAstLowering; use rustc_span::symbol::{kw, Ident};
Code change:
<!-- 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.

Related discussion:
text: } fn visit_ty(&mut self, t: &'ast Ty) { <del> match t.kind { </del> <ins> match &t.kind { TyKind::Path(None, _) => { // We can sometimes encounter bare trait objects // which are represented in AST as paths. if let Some(partial_res) = self.resolver.get_partial_res(t.id) && let Some(Res::Def(DefKind::Trait | DefKind::TraitAlias, _)) = partial_res.full_res() { self.current_binders.push(t.id); visit::walk_ty(self, t); self.current_binders.pop(); } else { visit::walk_ty(self, t); } } </ins> TyKind::BareFn(_) => { self.current_binders.push(t.id); visit::walk_ty(self, t);
Code change:
<!-- 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.

Related discussion:
text: <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>
Code change:
<!-- 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.

Related discussion:
text: <ins> warning: trait objects without an explicit `dyn` are deprecated --> $DIR/fresh-lifetime-from-bare-trait-obj-114664.rs:5:24 | LL | fn ice() -> impl AsRef<Fn(&())> { |                        ^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> = note: `#[warn(bare_trait_objects)]` on by default help: use `dyn` | LL | fn ice() -> impl AsRef<dyn Fn(&())> { |                        +++ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/fresh-lifetime-from-bare-trait-obj-114664.rs:5:24 | LL | fn ice() -> impl AsRef<Fn(&())> { |                        ^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> help: use `dyn` | LL | fn ice() -> impl AsRef<dyn Fn(&())> { |                        +++ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/fresh-lifetime-from-bare-trait-obj-114664.rs:5:24 | LL | fn ice() -> impl AsRef<Fn(&())> { |                        ^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> help: use `dyn` | LL | fn ice() -> impl AsRef<dyn Fn(&())> { |                        +++ warning: 3 warnings emitted </ins>
Code change:
Bug originally found by , which I've then reduced. I tried this code: I expected to see this happen: Instead, this happened: code compiles successfully and onwards modify labels: +I-unsound +regression-from-stable-to-stable -regression-untriaged This does not occur if the implied-lifetime-bounds array is in closure parameter position; so it looks like a bug w.r.t. not properly checking the closure output type implied bounds?does not help (as of )
Bisected to nightly-2022-08-10: <- looks maybe interesting
you beat me by one minute :) cc for being possible cause of this unsoundness?
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler -needs-triage
Oh, neat it did turn out to be a new soundness bug instead of a dupe of . Thanks for figuring out this was a regression,
for we have a terminator calling , i.e. a function which returns . This does not include the implied bounds. Checking that is WF requires proving which succeeds without checking the usable implied bounds of the trait-ref. edit: there's a bit more to this than I thought
This soundness bug is effectively only reproducible via the traits because the impls for it are builtin and so a little screwy. An attempt to write an explicit impl for the builtin impls would require an explicit bound that holds which is not present on the builtin impl. There is an assumption that all it takes for an assoc type to be wf is the where clauses on it and the impl hold, and that all arguments in the traitref are wf. The builtin impls violate this by not having the required implied bound on the impl so we end up with being able to be proven wf without proving the implied bounds. When calling we check that the fn sig of is wf which is . Before we would check the normalized signature is wf so the return type would be which would cause us to prove . Now that we check the unnormalized_ signature is wf we end up never seeing the normalized form with the which introduces the implied bound. It is generally an invariant of the type system that holding should imply also holds. The fact that can be well formed but is not, is concerning. In an ideal world proving the traits would require also proving all the implied bounds hold but right now that is not possible afaik. A simple fix (albeit hacky until we make implied bounds desugared to actual bounds) would be to make us also check not just .

Related discussion:
text: return; } }; <del> let (sig, map) = tcx.instantiate_bound_regions(sig, |br| { </del> <ins> let (unnormalized_sig, map) = tcx.instantiate_bound_regions(sig, |br| { </ins> use crate::renumber::RegionCtxt; let region_ctxt_fn = || {
Code change:
Bug originally found by , which I've then reduced. I tried this code: I expected to see this happen: Instead, this happened: code compiles successfully and onwards modify labels: +I-unsound +regression-from-stable-to-stable -regression-untriaged This does not occur if the implied-lifetime-bounds array is in closure parameter position; so it looks like a bug w.r.t. not properly checking the closure output type implied bounds?does not help (as of )
Bisected to nightly-2022-08-10: <- looks maybe interesting
you beat me by one minute :) cc for being possible cause of this unsoundness?
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler -needs-triage
Oh, neat it did turn out to be a new soundness bug instead of a dupe of . Thanks for figuring out this was a regression,
for we have a terminator calling , i.e. a function which returns . This does not include the implied bounds. Checking that is WF requires proving which succeeds without checking the usable implied bounds of the trait-ref. edit: there's a bit more to this than I thought
This soundness bug is effectively only reproducible via the traits because the impls for it are builtin and so a little screwy. An attempt to write an explicit impl for the builtin impls would require an explicit bound that holds which is not present on the builtin impl. There is an assumption that all it takes for an assoc type to be wf is the where clauses on it and the impl hold, and that all arguments in the traitref are wf. The builtin impls violate this by not having the required implied bound on the impl so we end up with being able to be proven wf without proving the implied bounds. When calling we check that the fn sig of is wf which is . Before we would check the normalized signature is wf so the return type would be which would cause us to prove . Now that we check the unnormalized_ signature is wf we end up never seeing the normalized form with the which introduces the implied bound. It is generally an invariant of the type system that holding should imply also holds. The fact that can be well formed but is not, is concerning. In an ideal world proving the traits would require also proving all the implied bounds hold but right now that is not possible afaik. A simple fix (albeit hacky until we make implied bounds desugared to actual bounds) would be to make us also check not just .

Related discussion:
text: region_ctxt_fn, ) }); <del> debug!(?sig); </del> <ins> debug!(?unnormalized_sig); </ins> // IMPORTANT: We have to prove well formed for the function signature before // we normalize it, as otherwise types like `<&'a &'b () as Trait>::Assoc` // get normalized away, causing us to ignore the `'b: 'a` bound used by the function.
Code change:
Bug originally found by , which I've then reduced. I tried this code: I expected to see this happen: Instead, this happened: code compiles successfully and onwards modify labels: +I-unsound +regression-from-stable-to-stable -regression-untriaged This does not occur if the implied-lifetime-bounds array is in closure parameter position; so it looks like a bug w.r.t. not properly checking the closure output type implied bounds?does not help (as of )
Bisected to nightly-2022-08-10: <- looks maybe interesting
you beat me by one minute :) cc for being possible cause of this unsoundness?
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler -needs-triage
Oh, neat it did turn out to be a new soundness bug instead of a dupe of . Thanks for figuring out this was a regression,
for we have a terminator calling , i.e. a function which returns . This does not include the implied bounds. Checking that is WF requires proving which succeeds without checking the usable implied bounds of the trait-ref. edit: there's a bit more to this than I thought
This soundness bug is effectively only reproducible via the traits because the impls for it are builtin and so a little screwy. An attempt to write an explicit impl for the builtin impls would require an explicit bound that holds which is not present on the builtin impl. There is an assumption that all it takes for an assoc type to be wf is the where clauses on it and the impl hold, and that all arguments in the traitref are wf. The builtin impls violate this by not having the required implied bound on the impl so we end up with being able to be proven wf without proving the implied bounds. When calling we check that the fn sig of is wf which is . Before we would check the normalized signature is wf so the return type would be which would cause us to prove . Now that we check the unnormalized_ signature is wf we end up never seeing the normalized form with the which introduces the implied bound. It is generally an invariant of the type system that holding should imply also holds. The fact that can be well formed but is not, is concerning. In an ideal world proving the traits would require also proving all the implied bounds hold but right now that is not possible afaik. A simple fix (albeit hacky until we make implied bounds desugared to actual bounds) would be to make us also check not just .

Related discussion:
text: // // See #91068 for an example. self.prove_predicates( <del> sig.inputs_and_output.iter().map(|ty| { </del> <ins> unnormalized_sig.inputs_and_output.iter().map(|ty| { </ins> ty::Binder::dummy(ty::PredicateKind::Clause(ty::ClauseKind::WellFormed( ty.into(), )))
Code change:
Bug originally found by , which I've then reduced. I tried this code: I expected to see this happen: Instead, this happened: code compiles successfully and onwards modify labels: +I-unsound +regression-from-stable-to-stable -regression-untriaged This does not occur if the implied-lifetime-bounds array is in closure parameter position; so it looks like a bug w.r.t. not properly checking the closure output type implied bounds?does not help (as of )
Bisected to nightly-2022-08-10: <- looks maybe interesting
you beat me by one minute :) cc for being possible cause of this unsoundness?
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler -needs-triage
Oh, neat it did turn out to be a new soundness bug instead of a dupe of . Thanks for figuring out this was a regression,
for we have a terminator calling , i.e. a function which returns . This does not include the implied bounds. Checking that is WF requires proving which succeeds without checking the usable implied bounds of the trait-ref. edit: there's a bit more to this than I thought
This soundness bug is effectively only reproducible via the traits because the impls for it are builtin and so a little screwy. An attempt to write an explicit impl for the builtin impls would require an explicit bound that holds which is not present on the builtin impl. There is an assumption that all it takes for an assoc type to be wf is the where clauses on it and the impl hold, and that all arguments in the traitref are wf. The builtin impls violate this by not having the required implied bound on the impl so we end up with being able to be proven wf without proving the implied bounds. When calling we check that the fn sig of is wf which is . Before we would check the normalized signature is wf so the return type would be which would cause us to prove . Now that we check the unnormalized_ signature is wf we end up never seeing the normalized form with the which introduces the implied bound. It is generally an invariant of the type system that holding should imply also holds. The fact that can be well formed but is not, is concerning. In an ideal world proving the traits would require also proving all the implied bounds hold but right now that is not possible afaik. A simple fix (albeit hacky until we make implied bounds desugared to actual bounds) would be to make us also check not just .

Related discussion:
text: term_location.to_locations(), ConstraintCategory::Boring, ); <del> let sig = self.normalize(sig, term_location); </del> <ins> let sig = self.normalize(unnormalized_sig, term_location); // HACK(#114936): `WF(sig)` does not imply `WF(normalized(sig))` // with built-in `Fn` implementations, since the impl may not be // well-formed itself. if sig != unnormalized_sig { self.prove_predicates( sig.inputs_and_output.iter().map(|ty| { ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::WellFormed(ty.into()), )) }), term_location.to_locations(), ConstraintCategory::Boring, ); } </ins> self.check_call_dest(body, term, &sig, *destination, *target, term_location); // The ordinary liveness rules will ensure that all