Question:
The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)

LL | fn test_many_bounds_where<X>(x: X) where X: Sized, X: Sized, X: Debug { |                                                            ^^^^^^^^^^ <del> error: aborting due to 6 previous errors </del> <ins> error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/bound-suggestions.rs:44:46 | LL |     const SIZE: usize = core::mem::size_of::<Self>(); |                                              ^^^^ doesn't have a size known at compile-time | ::: $SRC_DIR/core/src/mem/mod.rs:LL:COL | LL | pub const fn size_of<T>() -> usize { |                      - required by this bound in `std::mem::size_of` | help: consider further restricting `Self` | LL | trait Foo<T>: Sized { |             ^^^^^^^ error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/bound-suggestions.rs:49:46 | LL |     const SIZE: usize = core::mem::size_of::<Self>(); |                                              ^^^^ doesn't have a size known at compile-time | ::: $SRC_DIR/core/src/mem/mod.rs:LL:COL | LL | pub const fn size_of<T>() -> usize { |                      - required by this bound in `std::mem::size_of` | help: consider further restricting `Self` | LL | trait Bar: std::fmt::Display + Sized { |                              ^^^^^^^ error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/bound-suggestions.rs:54:46 | LL |     const SIZE: usize = core::mem::size_of::<Self>(); |                                              ^^^^ doesn't have a size known at compile-time | ::: $SRC_DIR/core/src/mem/mod.rs:LL:COL | LL | pub const fn size_of<T>() -> usize { |                      - required by this bound in `std::mem::size_of` | help: consider further restricting `Self` | LL | trait Baz: Sized where Self: std::fmt::Display { |          ^^^^^^^ error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/bound-suggestions.rs:59:46 | LL |     const SIZE: usize = core::mem::size_of::<Self>(); |                                              ^^^^ doesn't have a size known at compile-time | ::: $SRC_DIR/core/src/mem/mod.rs:LL:COL | LL | pub const fn size_of<T>() -> usize { |                      - required by this bound in `std::mem::size_of` | help: consider further restricting `Self` | LL | trait Qux<T>: Sized where Self: std::fmt::Display { |             ^^^^^^^ error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/bound-suggestions.rs:64:46 | LL |     const SIZE: usize = core::mem::size_of::<Self>(); |                                              ^^^^ doesn't have a size known at compile-time | ::: $SRC_DIR/core/src/mem/mod.rs:LL:COL | LL | pub const fn size_of<T>() -> usize { |                      - required by this bound in `std::mem::size_of` | help: consider further restricting `Self` | LL | trait Bat<T>: std::fmt::Display + Sized { |                                 ^^^^^^^ error: aborting due to 11 previous errors </ins> For more information about this error, try `rustc --explain E0277`.


Question:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

.iter() .enumerate() .map(|(i, ty)| Argument { <del> name: Symbol::intern(&rustc_hir_pretty::param_to_string(&body.params[i])), </del> <ins> name: name_from_pat(&body.params[i].pat), </ins> type_: ty.clean(cx), }) .collect(),


Question:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

Path { global: path.global, res: path.res, segments } } <ins> crate fn qpath_to_string(p: &hir::QPath<'_>) -> String { let segments = match *p { hir::QPath::Resolved(_, ref path) => &path.segments, hir::QPath::TypeRelative(_, ref segment) => return segment.ident.to_string(), hir::QPath::LangItem(lang_item, ..) => return lang_item.name().to_string(), }; let mut s = String::new(); for (i, seg) in segments.iter().enumerate() { if i > 0 { s.push_str("::"); } if seg.ident.name != kw::PathRoot { s.push_str(&seg.ident.as_str()); } } s } </ins> crate fn build_deref_target_impls(cx: &DocContext<'_>, items: &[Item], ret: &mut Vec<Item>) { let tcx = cx.tcx;


Question:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

} } <ins> crate fn name_from_pat(p: &hir::Pat<'_>) -> Symbol { use rustc_hir::*; debug!("trying to get a name from pattern: {:?}", p); Symbol::intern(&match p.kind { PatKind::Wild => return kw::Underscore, PatKind::Binding(_, _, ident, _) => return ident.name, PatKind::TupleStruct(ref p, ..) | PatKind::Path(ref p) => qpath_to_string(p), PatKind::Struct(ref name, ref fields, etc) => format!( "{} {{ {}{} }}", qpath_to_string(name), fields .iter() .map(|fp| format!("{}: {}", fp.ident, name_from_pat(&fp.pat))) .collect::<Vec<String>>() .join(", "), if etc { ", .." } else { "" } ), PatKind::Or(ref pats) => pats .iter() .map(|p| name_from_pat(&**p).to_string()) .collect::<Vec<String>>() .join(" | "), PatKind::Tuple(ref elts, _) => format!( "({})", elts.iter() .map(|p| name_from_pat(&**p).to_string()) .collect::<Vec<String>>() .join(", ") ), PatKind::Box(ref p) => return name_from_pat(&**p), PatKind::Ref(ref p, _) => return name_from_pat(&**p), PatKind::Lit(..) => { warn!( "tried to get argument name from PatKind::Lit, which is silly in function arguments" ); return Symbol::intern("()"); } PatKind::Range(..) => return kw::Underscore, PatKind::Slice(ref begin, ref mid, ref end) => { let begin = begin.iter().map(|p| name_from_pat(&**p).to_string()); let mid = mid.as_ref().map(|p| format!("..{}", name_from_pat(&**p))).into_iter(); let end = end.iter().map(|p| name_from_pat(&**p).to_string()); format!("[{}]", begin.chain(mid).chain(end).collect::<Vec<_>>().join(", ")) } }) } </ins> crate fn print_const(cx: &DocContext<'_>, n: &'tcx ty::Const<'_>) -> String { match n.val { ty::ConstKind::Unevaluated(def, _, promoted) => {


Question:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

<ins> // Rustdoc shouldn't display `mut` in function arguments, which are // implementation details. Regression test for #81289. #![crate_name = "foo"] pub struct Foo; // @count foo/struct.Foo.html '//*[@class="impl-items"]//*[@class="method"]' 2 // @!has - '//*[@class="impl-items"]//*[@class="method"]' 'mut' impl Foo { pub fn foo(mut self) {} pub fn bar(mut bar: ()) {} } // @count foo/fn.baz.html '//*[@class="rust fn"]' 1 // @!has - '//*[@class="rust fn"]' 'mut' pub fn baz(mut foo: Foo) {} </ins>


Question:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

#![crate_name = "foo"] // @has foo/fn.f.html <del> // @has - '//*[@class="rust fn"]' 'pub fn f(0u8 ...255: u8)' </del> <ins> // @has - '//*[@class="rust fn"]' 'pub fn f(_: u8)' </ins> pub fn f(0u8...255: u8) {}


Question:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc

use crate::{lang_items, LangItem, LanguageItems}; use rustc_ast as ast; <del> use rustc_data_structures::fx::FxHashMap; </del> <ins> use rustc_data_structures::stable_map::StableMap; </ins> use rustc_span::symbol::{sym, Symbol}; use std::lazy::SyncLazy;


Question:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc

macro_rules! weak_lang_items { ($($name:ident, $item:ident, $sym:ident;)*) => ( <del> pub static WEAK_ITEMS_REFS: SyncLazy<FxHashMap<Symbol, LangItem>> = SyncLazy::new(|| { let mut map = FxHashMap::default(); </del> <ins> pub static WEAK_ITEMS_REFS: SyncLazy<StableMap<Symbol, LangItem>> = SyncLazy::new(|| { let mut map = StableMap::default(); </ins> $(map.insert(sym::$name, LangItem::$item);)* map });


Question:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc

} } <del> for (name, &item) in WEAK_ITEMS_REFS.iter() { </del> <ins> for (name, item) in WEAK_ITEMS_REFS.clone().into_sorted_vector().into_iter() { </ins> if missing.contains(&item) && required(tcx, item) && items.require(item).is_err() { if item == LangItem::PanicImpl { tcx.sess.err("`#[panic_handler]` function required, but not found");


Question:
The following comment causes a panic in jsondocck currently: Expected: Pretty error like 'Invalid split pattern on line X' Current: Giant stack trace, only obvious if you know what that line is doing. Opening this for tracking and so I don't forget to fix it <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (since you said "so I don't forget to fix it")

} } <del> let args = cap.name("args").map_or(vec![], |m| shlex::split(m.as_str()).unwrap()); </del> <ins> let args = cap.name("args").map_or(Some(vec![]), |m| shlex::split(m.as_str())); let args = match args { Some(args) => args, None => { print_err( &format!( "Invalid arguments to shlex::split: `{}`", cap.name("args").unwrap().as_str() ), lineno, ); errors = true; continue; } }; </ins> if !cmd.validate(&args, commands.len(), lineno) { errors = true;


Question:
<!-- 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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

"deref-methods-{:#}", type_.print(cx.cache()) ))); <ins> debug!("Adding {} to deref id map", type_.print(cx.cache())); </ins> cx.deref_id_map .borrow_mut() .insert(type_.def_id_full(cx.cache()).unwrap(), id.clone());


Question:
<!-- 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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

_ => None, }) .expect("Expected associated type binding"); <ins> debug!("Render deref methods for {:#?}, target {:#?}", impl_.inner_impl().for_, target); </ins> let what = AssocItemRender::DerefFor { trait_: deref_type, type_: real_target, deref_mut_: deref_mut }; if let Some(did) = target.def_id_full(cx.cache()) {


Question:
<!-- 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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

}) { debug!("found target, real_target: {:?} {:?}", target, real_target); <ins> if let Some(did) = target.def_id_full(cx.cache()) { if let Some(type_did) = impl_.inner_impl().for_.def_id_full(cx.cache()) { // `impl Deref<Target = S> for S` if did == type_did { // Avoid infinite cycles return; } } } </ins> let deref_mut = v .iter() .filter(|i| i.inner_impl().trait_.is_some())


Question:
<!-- 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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

.filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cx.cache()) == c.deref_trait_did) { <del> if let Some(type_did) = impl_.inner_impl().for_.def_id_full(cx.cache()) { // `impl Deref<Target = S> for S` if target_did == type_did { // Avoid infinite cycles return; } } </del> sidebar_deref_methods(cx, out, target_deref_impl, target_impls); } }


Question:
<!-- 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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

<ins> // check-pass // #81395: Fix ICE when recursing into Deref target only differing in type args pub struct Generic<T>(T); impl<'a> std::ops::Deref for Generic<&'a mut ()> { type Target = Generic<&'a ()>; fn deref(&self) -> &Self::Target { unimplemented!() } } impl<'a> Generic<&'a ()> { pub fn some_method(&self) {} } </ins>


Question:
This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim

true } }); <del> return INTERNER.intern_path(sysroot); </del> } // Symlink the source root into the same location inside the sysroot,


Question:
This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim

stable = $stable:expr $(,tool_std = $tool_std:literal)? $(,allow_features = $allow_features:expr)? <ins> $(,add_bins_to_sysroot = $add_bins_to_sysroot:expr)? </ins> ;)+) => { $( #[derive(Debug, Clone, Hash, PartialEq, Eq)]


Question:
This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim

#[allow(unused_mut)] fn run(mut $sel, $builder: &Builder<'_>) -> Option<PathBuf> { <del> $builder.ensure(ToolBuild { </del> <ins> let tool = $builder.ensure(ToolBuild { </ins> compiler: $sel.compiler, target: $sel.target, tool: $tool_name,


Question:
This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim

is_optional_tool: true, source_type: SourceType::InTree, allow_features: concat!($($allow_features)*), <del> }) </del> <ins> })?; if (false $(|| !$add_bins_to_sysroot.is_empty())?) && $sel.compiler.stage > 0 { let bindir = $builder.sysroot($sel.compiler).join("bin"); t!(fs::create_dir_all(&bindir)); #[allow(unused_variables)] let tools_out = $builder .cargo_out($sel.compiler, Mode::ToolRustc, $sel.target); $(for add_bin in $add_bins_to_sysroot { let bin_source = tools_out.join(exe(add_bin, $sel.target)); let bin_destination = bindir.join(exe(add_bin, $sel.compiler.host)); $builder.copy(&bin_source, &bin_destination); })? let tool = bindir.join(exe($tool_name, $sel.compiler.host)); Some(tool) } else { Some(tool) } </ins> } } )+


Question:
This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim

tool_extended!((self, builder), Cargofmt, "src/tools/rustfmt", "cargo-fmt", stable=true; CargoClippy, "src/tools/clippy", "cargo-clippy", stable=true; <del> Clippy, "src/tools/clippy", "clippy-driver", stable=true; Miri, "src/tools/miri", "miri", stable=false; CargoMiri, "src/tools/miri/cargo-miri", "cargo-miri", stable=true; </del> <ins> Clippy, "src/tools/clippy", "clippy-driver", stable=true, add_bins_to_sysroot = ["clippy-driver", "cargo-clippy"]; Miri, "src/tools/miri", "miri", stable=false, add_bins_to_sysroot = ["miri"]; CargoMiri, "src/tools/miri/cargo-miri", "cargo-miri", stable=true, add_bins_to_sysroot = ["cargo-miri"]; </ins> // FIXME: tool_std is not quite right, we shouldn't allow nightly features. // But `builder.cargo` doesn't know how to handle ToolBootstrap in stages other than 0, // and this is close enough for now. Rls, "src/tools/rls", "rls", stable=true, tool_std=true; RustDemangler, "src/tools/rust-demangler", "rust-demangler", stable=false, tool_std=true; <del> Rustfmt, "src/tools/rustfmt", "rustfmt", stable=true; </del> <ins> Rustfmt, "src/tools/rustfmt", "rustfmt", stable=true, add_bins_to_sysroot = ["rustfmt", "cargo-fmt"]; </ins> ); impl<'a> Builder<'a> {


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

if builder.config.llvm_thin_lto { cfg.define("LLVM_ENABLE_LTO", "Thin"); if !target.contains("apple") { <del> cfg.define("LLVM_USE_LINKER", "lld"); </del> <ins> cfg.define("LLVM_ENABLE_LLD", "ON"); </ins> } }


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

t!(fs::create_dir_all(&out_dir)); let mut cfg = cmake::Config::new(builder.src.join("src/llvm-project/lld")); <del> if let Some(ref linker) = builder.config.llvm_use_linker { cfg.define("LLVM_USE_LINKER", linker); } </del> configure_cmake(builder, target, &mut cfg, true); // This is an awful, awful hack. Discovered when we migrated to using


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

--set target.i686-unknown-linux-gnu.linker=clang  --build=i686-unknown-linux-gnu  --set llvm.ninja=false  <del> --set llvm.use-linker=lld  --set rust.use-lld=true  </del> --set rust.jemalloc <del> ENV SCRIPT python3 ../x.py dist --build $HOSTS --host $HOSTS --target $HOSTS </del> <ins> ENV SCRIPT python2.7 ../x.py dist --build $HOSTS --host $HOSTS --target $HOSTS </ins> ENV CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_LINKER=clang # This was added when we switched from gcc to clang. It's not clear why this is


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ RUN ./build-gcc.sh && apt-get remove -y gcc g++ <del> # Debian 6 has Python 2.6 by default, but LLVM >= 12 needs Python 3 </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # LLVM needs cmake 3.13.4 or higher </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. </ins> COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

--set target.x86_64-unknown-linux-gnu.ranlib=/rustroot/bin/llvm-ranlib  --set llvm.thin-lto=true  --set llvm.ninja=false  <del> --set llvm.use-linker=lld  --set rust.use-lld=true  </del> --set rust.jemalloc <del> ENV SCRIPT ../src/ci/pgo.sh python3 ../x.py dist  </del> <ins> ENV SCRIPT ../src/ci/pgo.sh python2.7 ../x.py dist  </ins> --host $HOSTS --target $HOSTS  --include-default-paths  src/tools/build-manifest


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

source shared.sh <del> LLVM=llvmorg-11.0.1 </del> <ins> LLVM=llvmorg-10.0.0 </ins> mkdir llvm-project cd llvm-project


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

set -ex source shared.sh <del> curl https://www.python.org/ftp/python/3.9.1/Python-3.9.1.tgz |  </del> <ins> curl https://www.python.org/ftp/python/2.7.12/Python-2.7.12.tgz |  </ins> tar xzf - mkdir python-build


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

# Gotta do some hackery to tell python about our custom OpenSSL build, but other # than that fairly normal. CFLAGS='-I /rustroot/include' LDFLAGS='-L /rustroot/lib -L /rustroot/lib64'  <del> hide_output ../Python-3.9.1/configure --prefix=/rustroot </del> <ins> hide_output ../Python-2.7.12/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf python-build <del> rm -rf Python-3.9.1 </del> <ins> rm -rf Python-2.7.12 </ins>


Question:
When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.

rm -rf /tmp/rustc-pgo <del> python3 ../x.py build --target=$PGO_HOST --host=$PGO_HOST  </del> <ins> python2.7 ../x.py build --target=$PGO_HOST --host=$PGO_HOST  </ins> --stage 2 library/std --rust-profile-generate=/tmp/rustc-pgo ./build/$PGO_HOST/stage2/bin/rustc --edition=2018


Question:
<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced by <!-- 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.

LookupResult::Parent(Some(parent)) => { let (_maybe_live, maybe_dead) = self.init_data.maybe_live_dead(parent); if maybe_dead { <del> span_bug!( </del> <ins> self.tcx.sess.delay_span_bug( </ins> terminator.source_info.span, <del> "drop of untracked, uninitialized value {:?}, place {:?} ({:?})", bb, place, path </del> <ins> &format!( "drop of untracked, uninitialized value {:?}, place {:?} ({:?})", bb, place, path, ), </ins> ); } continue;


Question:
<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced by <!-- 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.

bb, ), LookupResult::Parent(..) => { <del> span_bug!( </del> <ins> self.tcx.sess.delay_span_bug( </ins> terminator.source_info.span, <del> "drop of untracked value {:?}", bb </del> <ins> &format!("drop of untracked value {:?}", bb), </ins> ); } }


Question:
<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced by <!-- 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.

<ins> // Regression test for issue 81708 and issue 91816 where running a drop // elaboration on a MIR which failed borrowck lead to an ICE. static A: () = { let a: [String; 1]; //~^ ERROR destructors cannot be evaluated at compile-time a[0] = String::new(); //~^ ERROR destructors cannot be evaluated at compile-time //~| ERROR use of possibly-uninitialized variable }; struct B<T>([T; 1]); impl<T> B<T> { pub const fn f(mut self, other: T) -> Self { let _this = self; //~^ ERROR destructors cannot be evaluated at compile-time self.0[0] = other; //~^ ERROR destructors cannot be evaluated at compile-time //~| ERROR use of moved value self } } fn main() {} </ins>


Question:
<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced by <!-- 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.

<ins> error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/drop-elaboration-after-borrowck-error.rs:7:5 | LL |     a[0] = String::new(); |     ^^^^ |     | |     statics cannot evaluate destructors |     value is dropped here error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/drop-elaboration-after-borrowck-error.rs:5:9 | LL |     let a: [String; 1]; |         ^ statics cannot evaluate destructors ... LL | }; | - value is dropped here error[E0381]: use of possibly-uninitialized variable: `a` --> $DIR/drop-elaboration-after-borrowck-error.rs:7:5 | LL |     a[0] = String::new(); |     ^^^^ use of possibly-uninitialized `a` error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/drop-elaboration-after-borrowck-error.rs:18:9 | LL |         self.0[0] = other; |         ^^^^^^^^^ |         | |         constant functions cannot evaluate destructors |         value is dropped here error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/drop-elaboration-after-borrowck-error.rs:16:13 | LL |         let _this = self; |             ^^^^^ constant functions cannot evaluate destructors ... LL |     } |     - value is dropped here error[E0382]: use of moved value: `self.0` --> $DIR/drop-elaboration-after-borrowck-error.rs:18:9 | LL |     pub const fn f(mut self, other: T) -> Self { |                    -------- move occurs because `self` has type `B<T>`, which does not implement the `Copy` trait LL |         let _this = self; |                     ---- value moved here LL | LL |         self.0[0] = other; |         ^^^^^^^^^ value used here after move error: aborting due to 6 previous errors Some errors have detailed explanations: E0381, E0382, E0493. For more information about an error, try `rustc --explain E0381`. </ins>


Question:
<!-- 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 ICE is related to : <!-- 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</detailsIdeally, would compile, but generic associated types in trait paths are currently not implemented. Maybe rustc could give a nice error message when the is missing.
Duplicate to and related heavily to others. But this has a nice minimal repro, so worth leaving open. Probably fixed by .
I've tested this locally and I can confirm that fixes this (with this change: ).

<ins> // Regression test for #81712. #![feature(generic_associated_types)] #![allow(incomplete_features)] trait A { type BType: B<AType = Self>; } trait B { type AType: A<BType = Self>; } trait C { type DType<T>: D<T, CType = Self>; //~^ ERROR: missing generics for associated type `C::DType` [E0107] } trait D<T> { type CType: C<DType = Self>; } fn main() {} </ins>


Question:
<!-- 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 ICE is related to : <!-- 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</detailsIdeally, would compile, but generic associated types in trait paths are currently not implemented. Maybe rustc could give a nice error message when the is missing.
Duplicate to and related heavily to others. But this has a nice minimal repro, so worth leaving open. Probably fixed by .
I've tested this locally and I can confirm that fixes this (with this change: ).

<ins> error[E0107]: missing generics for associated type `C::DType` --> $DIR/issue-81712-cyclic-traits.rs:14:10 | LL |     type DType<T>: D<T, CType = Self>; |          ^^^^^ expected 1 type argument | note: associated type defined here, with 1 type parameter: `T` --> $DIR/issue-81712-cyclic-traits.rs:14:10 | LL |     type DType<T>: D<T, CType = Self>; |          ^^^^^ - help: use angle brackets to add missing type argument | LL |     type DType<T><T>: D<T, CType = Self>; |               ^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </ins>


Question:
<!-- 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 think this issue is more than an internal compiler error, so I report here. I tried this code: The md5 of is: I expected to see this happen: normal compilation Instead, this happened: rustc crashes <!-- 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. --I test it on nightly, beta, and stable versions. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I am not sure whether it is a security-oriented bug. If so, please close this. But I guess it is ok to be public. Thanks.
This is an explicit : So just an ICE, just somebody used an instead of a .
is the that's being executed.
The problem is that the parsing code is attempting to emit a fatal error, but error emission cannot happen through the function. The stack looks something like this: Two potential fixes here: adjust so that it does not abort on panics or make anything running within the incapable of panicking. The latter is way harder and more prone to eventually break again. I think this is probably P-medium or thereabouts.
It seems like the implementation of is copied from [][1]'s : [1]:
Would this be safe? My understanding is if the callback panics then the pointer will potentially be in an inconsistent state and continuing execution will not be safe.
Well, not in the exact form it is now, but there are a couple avenues that could be explored to make it more resilient to closure panics – e.g. one could replace the old value with some sort of placeholder default while the original value is being processed.
Another test-case. Hope it can help. .
Assigning as discussed as part of the and removing .
No longer crashes due to

<ins> // error-pattern: this file contains an unclosed delimiter // error-pattern: mismatched closing delimiter: `]` // error-pattern: expected one of `)` or `,`, found `{` #![crate_name="0"] fn main() {} fn r()->i{0|{#[cfg(r(0{]0 </ins>


Question:
<!-- 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 think this issue is more than an internal compiler error, so I report here. I tried this code: The md5 of is: I expected to see this happen: normal compilation Instead, this happened: rustc crashes <!-- 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. --I test it on nightly, beta, and stable versions. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I am not sure whether it is a security-oriented bug. If so, please close this. But I guess it is ok to be public. Thanks.
This is an explicit : So just an ICE, just somebody used an instead of a .
is the that's being executed.
The problem is that the parsing code is attempting to emit a fatal error, but error emission cannot happen through the function. The stack looks something like this: Two potential fixes here: adjust so that it does not abort on panics or make anything running within the incapable of panicking. The latter is way harder and more prone to eventually break again. I think this is probably P-medium or thereabouts.
It seems like the implementation of is copied from [][1]'s : [1]:
Would this be safe? My understanding is if the callback panics then the pointer will potentially be in an inconsistent state and continuing execution will not be safe.
Well, not in the exact form it is now, but there are a couple avenues that could be explored to make it more resilient to closure panics – e.g. one could replace the old value with some sort of placeholder default while the original value is being processed.
Another test-case. Hope it can help. .
Assigning as discussed as part of the and removing .
No longer crashes due to

<ins> error: this file contains an unclosed delimiter --> $DIR/issue-81827.rs:11:27 | LL | fn r()->i{0|{#[cfg(r(0{]0 |          -  -             ^ |          |  | |          |  unclosed delimiter |          unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-81827.rs:11:27 | LL | fn r()->i{0|{#[cfg(r(0{]0 |          -  -             ^ |          |  | |          |  unclosed delimiter |          unclosed delimiter error: mismatched closing delimiter: `]` --> $DIR/issue-81827.rs:11:23 | LL | fn r()->i{0|{#[cfg(r(0{]0 |               -       ^^ mismatched closing delimiter |               |       | |               |       unclosed delimiter |               closing delimiter possibly meant for this error: expected one of `)` or `,`, found `{` --> $DIR/issue-81827.rs:11:23 | LL | fn r()->i{0|{#[cfg(r(0{]0 |                       ^ expected one of `)` or `,` error: aborting due to 4 previous errors </ins>


Question:
<!-- 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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

}; let last_expr_ty = self.node_ty(last_expr.hir_id); let needs_box = match (last_expr_ty.kind(), expected_ty.kind()) { <ins> (ty::Opaque(last_def_id, _), ty::Opaque(exp_def_id, _)) if last_def_id == exp_def_id => { StatementAsExpression::CorrectType } </ins> (ty::Opaque(last_def_id, last_bounds), ty::Opaque(exp_def_id, exp_bounds)) => { debug!( "both opaque, likely future {:?} {:?} {:?} {:?}", last_def_id, last_bounds, exp_def_id, exp_bounds ); <del> let last_hir_id = self.tcx.hir().local_def_id_to_hir_id(last_def_id.expect_local()); let exp_hir_id = self.tcx.hir().local_def_id_to_hir_id(exp_def_id.expect_local()); </del> <ins> let (last_local_id, exp_local_id) = match (last_def_id.as_local(), exp_def_id.as_local()) { (Some(last_hir_id), Some(exp_hir_id)) => (last_hir_id, exp_hir_id), (_, _) => return None, }; let last_hir_id = self.tcx.hir().local_def_id_to_hir_id(last_local_id); let exp_hir_id = self.tcx.hir().local_def_id_to_hir_id(exp_local_id); </ins> match ( &self.tcx.hir().expect_item(last_hir_id).kind, &self.tcx.hir().expect_item(exp_hir_id).kind,


Question:
<!-- 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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

<ins> // edition:2018 pub struct Test {} impl Test { pub async fn answer_str(&self, _s: &str) -> Test { Test {} } } </ins>


Question:
<!-- 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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

<ins> // aux-build:issue-81839.rs // edition:2018 extern crate issue_81839; async fn test(ans: &str, num: i32, cx: &issue_81839::Test) -> u32 { match num { 1 => { cx.answer_str("hi"); } _ => cx.answer_str("hi"), //~ `match` arms have incompatible types } 1 } fn main() {} </ins>


Question:
<!-- 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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

<ins> error[E0308]: `match` arms have incompatible types --> $DIR/issue-81839.rs:11:14 | LL | /     match num { LL | |         1 => { LL | |             cx.answer_str("hi"); | |             -------------------- | |             |                  | | |             |                  help: consider removing this semicolon | |             this is found to be of type `()` LL | |         } LL | |         _ => cx.answer_str("hi"), | |              ^^^^^^^^^^^^^^^^^^^ expected `()`, found opaque type LL | |     } | |_____- `match` arms have incompatible types | ::: $DIR/auxiliary/issue-81839.rs:6:49 | LL |       pub async fn answer_str(&self, _s: &str) -> Test { |                                                   ---- the `Output` of this `async fn`'s found opaque type | = note:     expected type `()` found opaque type `impl Future` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
<!-- 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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

| LL |         false => async_dummy().await, |                               ^^^^^^ <del> help: consider removing this semicolon and boxing the expressions | LL |             Box::new(async_dummy()) LL | LL |         } LL |         false => Box::new(async_dummy()), </del> <ins> help: consider removing this semicolon </ins> | <ins> LL |             async_dummy() |                         -- </ins> error[E0308]: `match` arms have incompatible types --> $DIR/match-prev-arm-needing-semi.rs:39:18


Question:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.

struct_span_err!(tcx.sess, span, E0733, "recursion in an `async fn` requires boxing") .span_label(span, "recursive `async fn`") .note("a recursive `async fn` must be rewritten to return a boxed `dyn Future`") <ins> .note( "consider using the `async_recursion` crate: https://crates.io/crates/async_recursion", ) </ins> .emit(); }