jiebi/CodeConvo huggingface dataset:
Change:
This is probably a smaller reproduction of .
If anyone has a quick and dirty idea for how to force an type to resolve, I think I could finish minifying the above pretty easily.
Same ICEs without async:
Updated reproducing code to remove need for .
I'm fairly certain this is related to the visibility of types that appear in an type. Specifically, in the code above, if in is changed to , it compiles fine.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
triage: P-high until we assess severity (the bug written depends on a feature flag) we want to know if that's really needed for the issue to reproduce.
fwiw, my guess is that the feature flag is not necessary, and that the relevant can be replaced by an .
So, for cleanup crew ICE-breakers who might take a look at this: (a) we should try to get a backtrace with line numbers (b) we should see if this is a regression and track down the cause (maybe jump back a few months and see if the corresponding nightly from that time works?) (c) it'd be interesting to see if we can remove the from the impl and thus reproduce on something that builds on stable. As noted, an inherent on could trigger it, or perhaps something like:
Downgrading priority for now until we can reproduce without the gate.
related
Interestingly enough, an inherent method like that does not reproduce the issue, so it appears the existential type in associated type position is also needed.
I just hit the same issue on nightly: Reproduction is huge though: Just it. This happened after I upgraded dependency from to . I don't see feature used in .
That is which was fixed two days ago. Try updating rustc.
Indeed, thanks!

Discussion:
<ins> #![feature(type_alias_impl_trait)] // edition:2018 use std::future::Future; pub trait Service<Request> { type Future: Future<Output = ()>; fn call(&mut self, req: Request) -> Self::Future; } // NOTE: the pub(crate) here is critical pub(crate) fn new() -> () {} pub struct A; impl Service<()> for A { type Future = impl Future<Output = ()>; fn call(&mut self, _: ()) -> Self::Future { async { new() } } } </ins>

<ins> // aux-build:collect_hidden_types.rs use collect_hidden_types::Service; use std::future::Future; use std::pin::Pin; use std::task::Context; // build-pass // edition:2018 extern crate collect_hidden_types; fn broken(mut a: collect_hidden_types::A, cx: &mut Context<'_>) { let mut fut = a.call(()); let _ = unsafe { Pin::new_unchecked(&mut fut) }.poll(cx); } pub async fn meeb(cx: &mut Context<'_>) { broken(collect_hidden_types::A, cx); } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Already fixed in Miri, but I have some PRs open that will break Miri again so I am waiting a bit before updating the submodule.
Tagging as check
Blocked on

Discussion:
<del> Subproject commit 974c8be95ec17cd986251d7700cd432a39576939 </del> <ins> Subproject commit a7891c05f7fdb329f68c991abbb39dafc1f6b4a5 </ins>
Change:
This code is reduced from issue--unused-parens- :
Another variation on this to include in a regression test:
cc
Ah yeah, I see the issue. There's an implicit invariant that there should be no or-patterns directly in the first column of the matrix, but this invariant is broken exactly when an or-pattern has a child that is itself an or-pattern. I should have documented that. Specifically this fails to preserve the invariant: I don't expect to have the bandwidth to work on rustc in the foreseeable future sadly. I anyone wants to try, I believe the fix could be as simple as replacing in the above function with a loop that calls (and not ). That will ensure that we recursively expand or-patterns as needed instead of just expanding the first one.
Yep, that did it. Thanks for the pointer. This issue is fixed by

Discussion:
/// Pushes a new row to the matrix. If the row starts with an or-pattern, this expands it. crate fn push(&mut self, row: PatStack<'p, 'tcx>) { if let Some(rows) = row.expand_or_pat() { <del> self.0.extend(rows); </del> <ins> for row in rows { // We recursively expand the or-patterns of the new rows. // This is necessary as we might have `0 | (1 | 2)` or e.g., `x @ 0 | x @ (1 | 2)`. self.push(row) } </ins> } else { self.0.push(row); }

<ins> #![feature(or_patterns)] fn main() { let 0 | (1 | 2) = 0; //~ ERROR refutable pattern in local binding match 0 { //~^ ERROR non-exhaustive patterns 0 | (1 | 2) => {} } } </ins>

<ins> error[E0005]: refutable pattern in local binding: `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered --> $DIR/issue-69875-should-have-been-expanded-earlier-non-exhaustive.rs:4:9 | LL |     let 0 | (1 | 2) = 0; |         ^^^^^^^^^^^ patterns `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered | = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html help: you might want to use `if let` to ignore the variant that isn't matched | LL |     if let 0 | (1 | 2) = 0 { /* */ } |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0004]: non-exhaustive patterns: `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered --> $DIR/issue-69875-should-have-been-expanded-earlier-non-exhaustive.rs:5:11 | LL |     match 0 { |           ^ patterns `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms error: aborting due to 2 previous errors Some errors have detailed explanations: E0004, E0005. For more information about an error, try `rustc --explain E0004`. </ins>

<ins> // check-pass #![feature(or_patterns)] fn main() { let 0 | (1 | _) = 0; if let 0 | (1 | 2) = 0 {} if let x @ 0 | x @ (1 | 2) = 0 {} } </ins>
Change:
Occasionally the builder fails due to a spurious build failure: The WebRender people prepared , but it did not land in yet. Once it lands, we'll need to update to point to the new commit. Putting it so we check in on it weekly during the infrastructure team meeting.
Discussed this at the infra meeting, there is a PR removing webrender. De-prioritizing.

Discussion:
// This takes much less time to build than all of Servo and supports stable Rust. packages: &["selectors"], }, <del> Test { name: "webrender", repo: "https://github.com/servo/webrender", sha: "a3d6e6894c5a601fa547c6273eb963ca1321c2bb", lock: None, packages: &[], }, </del> ]; fn main() {
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Discussion:
dependencies = [ "cargo_metadata 0.9.0", "if_chain", <del> "itertools 0.8.0", </del> <ins> "itertools 0.9.0", </ins> "lazy_static 1.4.0", "matches", "pulldown-cmark 0.7.0",

] [[package]] <ins> name = "itertools" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "284f18f85651fe11e8a991b2adb42cb078325c996ed026d994719efcfca1d54b" dependencies = [ "either", ] [[package]] </ins> name = "itoa" version = "0.4.4" source = "registry+https://github.com/rust-lang/crates.io-index"

<del> Subproject commit 329923edec41d0ddbea7f30ab12fca0436d459ae </del> <ins> Subproject commit 8485d40a3264b15b92d391e99cb3d1abf8f25025 </ins>
Change:
Seems to be a cargo issue: -Z Maybe cargo 0.44.0 should just ignore this flag with a warning instead?

Discussion:
self.clear_if_dirty(&my_out, &rustdoc); } <del> cargo.env("CARGO_TARGET_DIR", &out_dir).arg(cmd).arg("-Zconfig-profile"); </del> <ins> cargo.env("CARGO_TARGET_DIR", &out_dir).arg(cmd); if !self.local_rebuild { cargo.arg("-Zconfig-profile"); } </ins> let profile_var = |name: &str| { let profile = if self.config.rust_optimize { "RELEASE" } else { "DEV" };
Change:
This is a regression from the last couple of days. Looks like the compiler for something forever. Curiously, the run with completes successfully. I'll investigate in more detail. The list of tests: All of the tests are supposed to report errors.
Here's the backtrace:
Looks like this is caused by the recent unwinding changes. cc
GCC toolchain version on which this reproduced:
Does this happen with stage 1 rustc or stage 2 rustc?
Stage 1, e.g. I'll check stage 2 now.
( is confirmed to be the cause, removing .)
I have a pretty good idea of what the problem might be. I'm traveling right now but I'll try to have a PR up by tonight.
The issue doesn't reproduce with a stage 2 compiler. That's great news long term, but broken stage 1 still makes any compiler work involving testing hard.
I don't have a Windows machine to test on right now, but can you try marking and with in to see if that fixes the issue?
can you try marking and with in to see if that fixes the issue? It does! Thanks for a workaround.

Discussion:
Err(ManuallyDrop::into_inner(data.p)) }; <del> // Compatibility wrapper around the try intrinsic for bootstrap #[inline] </del> <ins> // Compatibility wrapper around the try intrinsic for bootstrap. // // We also need to mark it #[inline(never)] to work around a bug on MinGW // targets: the unwinding implementation was relying on UB, but this only // becomes a problem in practice if inlining is involved. #[cfg(not(bootstrap))] use intrinsics::r#try as do_try; #[cfg(bootstrap)] #[inline(never)] </ins> unsafe fn do_try(try_fn: fn(*mut u8), data: *mut u8, catch_fn: fn(*mut u8, *mut u8)) -> i32 { <del> #[cfg(not(bootstrap))] { intrinsics::r#try(try_fn, data, catch_fn) } #[cfg(bootstrap)] { use crate::mem::MaybeUninit; </del> <ins> use crate::mem::MaybeUninit; #[cfg(target_env = "msvc")] type TryPayload = [u64; 2]; #[cfg(not(target_env = "msvc"))] type TryPayload = *mut u8; let mut payload: MaybeUninit<TryPayload> = MaybeUninit::uninit(); let payload_ptr = payload.as_mut_ptr() as *mut u8; let r = intrinsics::r#try(try_fn, data, payload_ptr); if r != 0 { </ins> #[cfg(target_env = "msvc")] <del> type TryPayload = [u64; 2]; </del> <ins> { catch_fn(data, payload_ptr) } </ins> #[cfg(not(target_env = "msvc"))] <del> type TryPayload = *mut u8; let mut payload: MaybeUninit<TryPayload> = MaybeUninit::uninit(); let payload_ptr = payload.as_mut_ptr() as *mut u8; let r = intrinsics::r#try(try_fn, data, payload_ptr); if r != 0 { #[cfg(target_env = "msvc")] { catch_fn(data, payload_ptr) } #[cfg(not(target_env = "msvc"))] { catch_fn(data, payload.assume_init()) } </del> <ins> { catch_fn(data, payload.assume_init()) </ins> } <del> r </del> } <ins> r </ins> } // We consider unwinding to be rare, so mark this function as cold. However,

obj } <del> #[inline] </del> <ins> // See comment on do_try above for why #[inline(never)] is needed on bootstrap. #[cfg_attr(bootstrap, inline(never))] #[cfg_attr(not(bootstrap), inline)] </ins> fn do_call<F: FnOnce() -> R, R>(data: *mut u8) { unsafe { let data = data as *mut Data<F, R>;
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Discussion:
"clippy_lints", "compiletest_rs", "derive-new", <del> "git2", </del> "lazy_static 1.4.0", "regex", "rustc-workspace-hack",

<del> Subproject commit 8485d40a3264b15b92d391e99cb3d1abf8f25025 </del> <ins> Subproject commit 23549a8c362a403026432f65a6cb398cb10d44b7 </ins>
Change:
I tried this code: () The error message: I expected to see this happen: The error is reported on the line for . Instead, this happened: The error is reported for the closure… Nighty, Beta and Stable affected.
modify labels: +A-diagnostics +C-bug +D-incorrect (someone other than the issue creator do this?)
More minimal repro: The closure just needs to be exist anywhere inside . Even this code reports the same error: Edit: this triggers the same issue:
This is essentially the same issue as

Discussion:
<ins> fn main() { // this closure is fine, and should not get any error annotations let em = |v: f64| -> f64 { v }; let x: f64 = em(1i16.into()); let y: f64 = 0.01f64 * 1i16.into(); //~^ ERROR type annotations needed //~| HELP try using a fully qualified path } </ins>

<ins> error[E0284]: type annotations needed --> $DIR/issue-70082.rs:7:33 | LL |     let y: f64 = 0.01f64 * 1i16.into(); |                          -      ^^^^ |                          | |                          type must be known at this point | = note: cannot satisfy `<f64 as Mul<_>>::Output == f64` help: try using a fully qualified path to specify the expected types | LL |     let y: f64 = 0.01f64 * <i16 as Into<T>>::into(1i16); |                            +++++++++++++++++++++++    ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0284`. </ins>
Change:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Got same error with: It seems unrelated to the type of the const
claim
Reduced: Looks like a normalization failure to me, but that shouldn't happen for .
So I found the bug, is just outright missing : <hr/But also, it's worrying that an equivalent to this is missing for consts (even if it's not relevant here):
For the record, what I described above () isn't fixed, just worked around. EDIT: opened .

Discussion:
&mut self, constant: &mir::Constant<'tcx>, ) -> Result<ConstValue<'tcx>, ErrorHandled> { <del> match constant.literal.val { ty::ConstKind::Unevaluated(def_id, substs, promoted) => { let substs = self.monomorphize(&substs); self.cx .tcx() .const_eval_resolve(ty::ParamEnv::reveal_all(), def_id, substs, promoted, None) .map_err(|err| { if promoted.is_none() { self.cx .tcx() .sess .span_err(constant.span, "erroneous constant encountered"); } err }) } </del> <ins> match self.monomorphize(&constant.literal).val { ty::ConstKind::Unevaluated(def_id, substs, promoted) => self .cx .tcx() .const_eval_resolve(ty::ParamEnv::reveal_all(), def_id, substs, promoted, None) .map_err(|err| { if promoted.is_none() { self.cx .tcx() .sess .span_err(constant.span, "erroneous constant encountered"); } err }), </ins> ty::ConstKind::Value(value) => Ok(value), <del> _ => { let const_ = self.monomorphize(&constant.literal); if let ty::ConstKind::Value(value) = const_.val { Ok(value) } else { span_bug!(constant.span, "encountered bad ConstKind in codegen: {:?}", const_); } } </del> <ins> err => span_bug!( constant.span, "encountered bad ConstKind after monomorphizing: {:?}", err ), </ins> } }

<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash const L: usize = 4; pub trait Print<const N: usize> { fn print(&self) -> usize { N } } pub struct Printer; impl Print<L> for Printer {} fn main() { let p = Printer; assert_eq!(p.print(), 4); } </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70125-1.rs:2:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn main() { <()>::foo(); } trait Foo<const X: usize> { fn foo() -> usize { X } } impl Foo<{3}> for () {} </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70125-2.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>
Change:
It seems the decoding of [mutable] and [nonowned] is broken: specifically it seems they are ignored when applied on a struct in an external module, when another attribute follows. In particular, it seems that when more than one attribute is present, only the last_ attribute survives encode+decode, and the others are somehow lost.
Nominating for the production ready milestone.
Should be fixable with the following patch:
Fixed by .

Discussion:
} else { let mut ret = false; do csearch::get_item_attrs(tcx.cstore, did) |meta_items| { <del> ret = attr::contains_name(meta_items, attr); </del> <ins> ret = ret || attr::contains_name(meta_items, attr); </ins> } ret }

<ins> // Copyright 2013 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. extern mod extra; fn o<T: Owned>(_: &T) {} fn c<T: Const>(_: &T) {} fn main() { let x = extra::rc::rc_mut_from_owned(0); o(&x); //~ ERROR instantiating a type parameter with an incompatible type `extra::rc::RcMut<int>`, which does not fulfill `Owned` c(&x); //~ ERROR instantiating a type parameter with an incompatible type `extra::rc::RcMut<int>`, which does not fulfill `Const` } </ins>
Change:
I've come up with this example (): My understanding is that the error is caused by the obligation being on just (which means it's not retried when is unified with ), whereas it should be stalled on both and so that it's retried when either changes. Right now is limited to type inference variables, so its representation will need to change, and will need to expose constants too. I believe ran into this as well, but for WF obligations, not trait ones. I'm self-assigning this because I'm working on the fix (as part of a larger effort). cc
Note to self: the PR fixing this should also test this example (): The reason for this is that this second example has the type and const inference variables in different generic args of , meaning fixing it also requires changing this to :
I've definitely noticed problems with inference involving consts before, but wasn't able to pin down where the issue was stemming from. It would be great if this could be addressed once and for all.

Discussion:
// trait selection is because we don't have enough // information about the types in the trait. pending_obligation.stalled_on = <del> trait_ref_type_vars(self.selcx, data.to_poly_trait_ref()); </del> <ins> trait_ref_infer_vars(self.selcx, data.to_poly_trait_ref()); </ins> debug!( "process_predicate: pending obligation {:?} now stalled on {:?}",

Ok(None) => { let tcx = self.selcx.tcx(); pending_obligation.stalled_on = <del> trait_ref_type_vars(self.selcx, data.to_poly_trait_ref(tcx)); </del> <ins> trait_ref_infer_vars(self.selcx, data.to_poly_trait_ref(tcx)); </ins> ProcessResult::Unchanged } Ok(Some(os)) => ProcessResult::Changed(mk_pending(infcx, os)),

} } <del> /// Returns the set of type inference variables contained in a trait ref. fn trait_ref_type_vars<'a, 'tcx>( </del> <ins> /// Returns the set of inference variables contained in a trait ref. fn trait_ref_infer_vars<'a, 'tcx>( </ins> selcx: &mut SelectionContext<'a, 'tcx>, trait_ref: ty::PolyTraitRef<'tcx>, ) -> Vec<TyOrConstInferVar<'tcx>> {

<ins> // build-pass #![feature(const_generics)] #![allow(incomplete_features)] pub fn works() { let array/*: [_; _]*/ = default_array(); let _: [_; 4] = array; Foo::foo(&array); } pub fn didnt_work() { let array/*: [_; _]*/ = default_array(); Foo::foo(&array); let _: [_; 4] = array; } trait Foo { fn foo(&self) {} } impl Foo for [i32; 4] {} impl Foo for [i64; 8] {} // Only needed because `[_; _]` is not valid type syntax. fn default_array<T, const N: usize>() -> [T; N] where [T; N]: Default, { Default::default() } fn main() { works(); didnt_work(); } </ins>

<ins> // build-pass #![feature(const_generics)] #![allow(incomplete_features)] fn works() { let array/*: [u8; _]*/ = default_byte_array(); let _: [_; 4] = array; Foo::foo(&array); } fn didnt_work() { let array/*: [u8; _]*/ = default_byte_array(); Foo::foo(&array); let _: [_; 4] = array; } trait Foo<T> { fn foo(&self) {} } impl Foo<i32> for [u8; 4] {} impl Foo<i64> for [u8; 8] {} // Only needed because `[u8; _]` is not valid type syntax. fn default_byte_array<const N: usize>() -> [u8; N] where [u8; N]: Default, { Default::default() } fn main() { works(); didnt_work(); } </ins>
Change:
cc
I've hit this many times, and using fixes the issue for me.
Unfortunately, that doesn't help. I got the same error again after removing entire dir. I think I find the problem. does not encounter for env (which I set in my file).
Hence the bootstrap should be in rather than .
This line: We may need to remove in . Or support it properly.
I personally consider this a "user error" in some sense, in that there's a bunch of cargo flags you can set (either in .cargo/config or environment) that'll break x.py -- I don't think we should be removing them ourselves, personally, since it seems like it's hard to be sure that they're really not necessary. I would also not want to support them, though... However, with specifically, it seems fine to just drop it from the environment. I would accept a PR doing so in

Discussion:
if self.clean and os.path.exists(build_dir): shutil.rmtree(build_dir) env = os.environ.copy() <ins> # `CARGO_BUILD_TARGET` breaks bootstrap build. # See also: <https://github.com/rust-lang/rust/issues/70208>. if "CARGO_BUILD_TARGET" in env: del env["CARGO_BUILD_TARGET"] </ins> env["RUSTC_BOOTSTRAP"] = '1' env["CARGO_TARGET_DIR"] = build_dir env["RUSTC"] = self.rustc()
Change:
<!-- 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: no warning is emitted. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'm not sure this needs to block , but it affects it, so marking as blocking for now.
claim
This is actually not an issue related to const generics :sweat_smile: It does not look at trait impls even if they are used as long as they don't overwrite the relevant method.

Discussion:
//         - This is because lang items are always callable from elsewhere. //   or //   2) We are not sure to be live or not <del> //     * Implementation of a trait method </del> <ins> //     * Implementations of traits and trait methods </ins> struct LifeSeeder<'k, 'tcx> { worklist: Vec<hir::HirId>, krate: &'k hir::Crate<'k>,

} } hir::ItemKind::Impl { ref of_trait, items, .. } => { <ins> if of_trait.is_some() { self.worklist.push(item.hir_id); } </ins> for impl_item_ref in items { let impl_item = self.krate.impl_item(impl_item_ref.id); if of_trait.is_some()

<ins> // check-pass #![feature(const_generics)] #![allow(incomplete_features)] #![deny(dead_code)] // We previously incorrectly linted `L` as unused here. const L: usize = 3; fn main() { let p = Printer {}; p.print(); } trait Print<const N: usize> { fn print(&self) -> usize { 3 } } struct Printer {} impl Print<L> for Printer {} </ins>

<ins> // check-pass #![deny(dead_code)] enum Foo { Bar, } fn main() { let p = [0; 0]; p.bar(); } trait Bar { fn bar(&self) -> usize { 3 } } impl Bar for [u32; Foo::Bar as usize] {} </ins>