Question: } } <del> // PGO does not work reliably with panic=unwind on Windows. Let's make it // an error to combine the two for now. It always runs into an assertions // if LLVM is built with assertions, but without assertions it sometimes // does not crash and will probably generate a corrupted binary. // We should only display this error if we're actually going to run PGO. // If we're just supposed to print out some data, don't show the error (#61002). if sess.opts.cg.profile_generate.enabled() && sess.target.is_like_msvc && sess.panic_strategy() == PanicStrategy::Unwind && sess.opts.prints.iter().all(|&p| p == PrintRequest::NativeStaticLibs) { sess.err( "Profile-guided optimization does not yet work in conjunction  with `-Cpanic=unwind` on Windows when targeting MSVC.  See issue #61002 <https://github.com/rust-lang/rust/issues/61002>  for more information.", ); } </del> // Sanitizers can only be used on platforms that we know have working sanitizer codegen. let supported_sanitizers = sess.target.options.supported_sanitizers; let unsupported_sanitizers = sess.opts.debugging_opts.sanitizer - supported_sanitizers;

LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?


Question: LL | | LL | |         |x| println!("doubling {}", x); LL | |         Some(x * 2) <del> | |         ----------- </del> <ins> | |         ----------- this tail expression is of type `std::option::Option<_>` </ins> LL | | LL | |     }); | |_____^ expected an `FnOnce<({integer},)>` closure, found `Option<_>`

I tried this code: searched nightlies: from nightly-2022-08-18 to nightly-2022-09-09 regressed nightly: nightly-2022-08-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Regression introduced in:
This block around is crucial to trigger the ICE.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: query upvars_mentioned(def_id: DefId) -> Option<&'tcx FxIndexMap<hir::HirId, hir::Upvar>> { desc { |tcx| "collecting upvars mentioned in `{}`", tcx.def_path_str(def_id) } } <del> query maybe_unused_trait_import(def_id: LocalDefId) -> bool { desc { |tcx| "maybe_unused_trait_import for `{}`", tcx.def_path_str(def_id.to_def_id()) } </del> <ins> query maybe_unused_trait_imports(_: ()) -> &'tcx FxIndexSet<LocalDefId> { desc { "fetching potentially unused trait imports" } </ins> } query maybe_unused_extern_crates(_: ()) -> &'tcx [(LocalDefId, Span)] { desc { "looking up all possibly unused extern crates" }

The resolver gathers a list of possibly unused trait imports in . This list is passed to resolver outputs, into the query. This query takes a and returns whether the import is possibly unused. This is used by the post-typeck unused import check in . This query iterates over all the statements in the crate, checks whether they may be unused trait imports, and warns if they are indeed unused. As there are typically very few unused trait imports compared to the number of items in a crate, it would make sense to directly iterate on . Steps: make an both in and , this will ensure a deterministic iteration order; rename query and give it the signature , and adapt the call site; we do not want to access directly, as this would prevent the query system from detecting that the set has not changed; in , inline and replace the loop over by a loop over ; the filter over there can be removed too (or replaced by a debug-assertion): the set may only point to use statements. Extra: investigate why we check for , and the consequences of removing that check; investigate the impact on perf of converting the to a simple when producing from . I am available on Zulip for any question. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still working on this?
Hello yes sorry for the super slow pace. I am still working on it (mostly reading the rustc dev guide so far). Is that alright or is it important to get this done quickly?
no worries, I am a beginner looking for tasks, hence the qn.


Question: let out = p.wait_with_output().unwrap(); assert!(!out.status.success()); let s = str::from_utf8(&out.stderr).unwrap(); <del> assert!(s.contains("stack backtrace") && s.contains("foo::h"), </del> <ins> assert!(s.contains("stack backtrace") && s.contains(" - foo"), </ins> "bad output: {}", s); // Make sure the stack trace is *not* printed

Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.


Question: if let ObligationCauseCode::WhereClause(_, span) | ObligationCauseCode::WhereClauseInExpr(_, span, ..) = &trace.cause.code().peel_derives() <del> && !span.is_dummy() </del> { let span = *span; <del> self.report_concrete_failure(generic_param_scope, placeholder_origin, sub, sup) .with_span_note(span, "the lifetime requirement is introduced here") </del> <ins> let mut err = self.report_concrete_failure( generic_param_scope, placeholder_origin, sub, sup, ); if !span.is_dummy() { err = err.with_span_note(span, "the lifetime requirement is introduced here"); } err </ins> } else { unreachable!( "control flow ensures we have a `BindingObligation` or `WhereClauseInExpr` here..."

: current nightly <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This did not used to ICE prior to The PR is in nightly-2024-05-12 and Rust 1.80. The diagnostic from nightly-2024-05-11 before that PR is:


Question: <ins> mod machine { pub struct A { pub b: B, } pub struct B {} impl B { pub fn f(&self) {} } } pub struct Context { pub a: machine::A, } pub fn ctx() -> Context { todo!(); } </ins>

EDIT (ehuss) Reproduction: Clone <!-- 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 --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.


Question: ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',


Question: ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,


Question: ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .


Question: ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .


Question: ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .


Question:
let cloned_shared = Rc::clone(&cx.shared); let cache = &cloned_shared.cache; let mut extern_crates = FxHashSet::default();  if !t.is_object_safe(cx.tcx()) { write_small_section_header( w, "object-safety", "Object Safety", &format!( "
This trait is not   object safe.
", base = crate::clean::utils::DOC_RUST_LANG_ORG_CHANNEL ), ); }  if let Some(implementors) = cache.implementors.get(&it.item_id.expect_def_id()) { // The DefId is for the first Type found with that name. The bool is // if any Types with the same name but different DefId have been found.

So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".


Question:
let cloned_shared = Rc::clone(&cx.shared); let cache = &cloned_shared.cache; let mut extern_crates = FxHashSet::default();  if !t.is_object_safe(cx.tcx()) { write_small_section_header( w, "object-safety", "Object Safety", &format!( "
This trait is not   object safe.
", base = crate::clean::utils::DOC_RUST_LANG_ORG_CHANNEL ), ); }  if let Some(implementors) = cache.implementors.get(&it.item_id.expect_def_id()) { // The DefId is for the first Type found with that name. The bool is // if any Types with the same name but different DefId have been found.

My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.


Question: node_to_hir_id: IndexVec::new(), macro_def_scopes: FxHashMap(), expansions: FxHashMap(), <del> keys_created: FxHashSet(), </del> <ins> next_disambiguator: FxHashMap(), </ins> } }

In investigating I was generating some source code, and using the shell script listed in we can see: That's a lot of time to expand a crate that doesn't have any macros in it!
cc you may be interested in this!
A looks like almost all the time is spent in In which case, cc
Apparently most time is spent
called ~38k times
Since we need to build the module graph and resolve imports during expansion for macros 2.0, we must construct node ids and def ids throughout expansion (i.e. interleaved arbitrarily many times until we hit fix-point). Ideally we'd keep running totals of the time spent assigning node ids, assigning def ids, etc. for more accurate profiling information within the expansion step.
in theory though isn't the fixed point for this crate the crate itself? (e.g. there's no macros here). Or are the def ids persisted for the rest of compilation, so "blaming" expansion isn't quite correct here?
Yeah, the def ids are persisted for the rest of compilation. We could move the "first round" of def id collection (in which we collect the raw, unexpanded source) outside of expansion, but that would introduce more code complexity and wouldn't count the time we spend collecting def ids for AST that comes from macro expansions.
Ah ok, nah it seems fine! I think there's a number of cases where is attributing time in the wrong place nowadays... Still it seems odd that 30-50k invocations of this function would take so long to execute?
Do I understand this correctly that all DefIds generated are actually used, right? There are no "temporary" DefIds? Each of these invocations creates a Blake2 hasher. I'd be interested how the performance looks with other hashing algorithms. I'd like to switch to something faster anyway:
Are you sure this isn't the other quadratic case fixed in ?
It may very well be! Feel free to close this w/ that PR landing, I'll verify to be sure but I'd imagine you're correct in that it's fixed by
er, didn't mean to close just yet


Question: node_to_hir_id: IndexVec::new(), macro_def_scopes: FxHashMap(), expansions: FxHashMap(), <del> keys_created: FxHashSet(), </del> <ins> next_disambiguator: FxHashMap(), </ins> } }

A of Servo's crate shows a huge amount of time (46 seconds!) in name resolution. It turns out that is calling , specifically . That's a lot of unused imports! Sure enough if we create a synthetic file locally with this script: we find: That's a lot of time spent processing unused imports! The slowdown here isn't quite the same as the style crate, unfortunately. The style crate only has ~7k unused imports, which apparently takes it 48s in that profile. In any case the intent here is clear, lots of unused imports seem to slow down compilation, and the crate looks to have a lot of unused imports!
cc
We could address this quickly by just emitting the first 10 unused imports warnings and then warning that there are more unused imports not shown.
I can never deal with more than 10 lints at a time anyway myself, so seems like a reasonable solution to me!
Dumping out a ton of warnings is useful when you're hooked into an IDE and you can see them as e.g. green squiggles under the offending text as opposed to 10k lines on a terminal.
I think the reason is slow is because it calls , which does this: I don't think we want to read source files multiple times like that.
Thank you for looking into Servo compile times Alex, and great find here! Could you CC me or someone from the Servo team for Servo-related issues? Thanks.
Can do!
In general I've always wanted the lint system to avoid even running in blocks. Currently the lint system runs all lints in parallel on the tree. This is great since it means we only traverse it once, and the cost of the traversal is consolidated. We don't need to reduce that cost itself (which is nice because then we don't have to worry about inside ). Most lints do not maintain state. The lint framework has the capability to do so, and we use this a couple times in Clippy, but most lints are , so they won't notice if or whatever isn't called in a region of . The "allowness" of a lint is tied to where in the tree the lint traversal is, not the span emitted by the lint.


Question: node_to_hir_id: IndexVec::new(), macro_def_scopes: FxHashMap(), expansions: FxHashMap(), <del> keys_created: FxHashSet(), </del> <ins> next_disambiguator: FxHashMap(), </ins> } }

It's perfectly possible to a block of code and have the lint still be emit there because a different block of code (where it is ) hit the lint but emitted a span it got from elsewhere. We've had trouble with this before in clipyp iirc. All of this enables this proposal: If we had a specialized trait for this, then when we have an we can turn off calling lint methods entirely, and when there's a turn it on again. It doesn't even have to be a trait, really, it could just be a defaulted fake-static method (until happens) on LateLintPass. I suspect this will get significant speedups for crates like Style. I may_ be able to take a crack at this if y'all think this is a good approach.
It occurs to me that a boolean check per lint each tree node might actually end up being more expensive? I'll have look at this code closer. Might be possible to make this fast by having a second array of trait objects which only contains the active lint passes.
It seems like we do a large enough amount of work that the whole "vector of active lints" stuff won't really be necessary. However, I just realized that this bug is not during the lint pass but during the resolution phase (which defers linting to the actual lint pass). This won't be able to help, though we can fix it by doing the spantosnippet in the actual lint and then making this optimization. So in that case I suspect this optimization is unnecessary. In general we've rarely had performance issues with lints in clippy (which has way more lints than rustc), and we've been pretty careful to measure impact there. Still, if folks think this optimization can help, let me know.


Question: v.iter().any(|&x| x == 0) } <del> #[inline(always)] fn from_utf8_with_replacement(mut v: &[u8]) -> ~str { // FIXME (#9516): Don't decode utf-8 manually here once we have a good way to do it in str // This is a truly horrifically bad implementation, done as a functionality stopgap until // we have a proper utf-8 decoder. I don't really want to write one here. static REPLACEMENT_CHAR: char = 'uFFFD'; let mut s = str::with_capacity(v.len()); while !v.is_empty() { let w = str::utf8_char_width(v[0]); if w == 0u { s.push_char(REPLACEMENT_CHAR); v = v.slice_from(1); } else if v.len() < w || !str::is_utf8(v.slice_to(w)) { s.push_char(REPLACEMENT_CHAR); v = v.slice_from(1); } else { s.push_str(unsafe { ::cast::transmute(v.slice_to(w)) }); v = v.slice_from(w); } } s } </del> #[cfg(test)] mod tests { use prelude::*;

We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is


Question: .map(|(item, renamed)| clean_maybe_renamed_foreign_item(cx, item, *renamed)), ); items.extend(self.mods.iter().map(|x| x.clean(cx))); <del> items.extend( self.items .iter() .flat_map(|(item, renamed)| clean_maybe_renamed_item(cx, item, *renamed)), ); </del> <ins> // Split up imports from all other items. // // This covers the case where somebody does an import which should pull in an item, // but there's already an item with the same namespace and same name. Rust gives // priority to the not-imported one, so we should, too. let mut inserted = FxHashSet::default(); items.extend(self.items.iter().flat_map(|(item, renamed)| { // First, lower everything other than imports. if matches!(item.kind, hir::ItemKind::Use(..)) { return Vec::new(); } let v = clean_maybe_renamed_item(cx, item, *renamed); for item in &v { if let Some(name) = item.name { inserted.insert((item.type_(), name)); } } v })); items.extend(self.items.iter().flat_map(|(item, renamed)| { // Now we actually lower the imports, skipping everything else. if !matches!(item.kind, hir::ItemKind::Use(..)) { return Vec::new(); } let mut v = clean_maybe_renamed_item(cx, item, *renamed); v.drain_filter(|item| { if let Some(name) = item.name { // If an item with the same type and name already exists, // it takes priority over the inlined stuff. !inserted.insert((item.type_(), name)) } else { false } }); v })); </ins> // determine if we should display the inner contents or // the outer `mod` item for the source code.

I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- 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<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.


Question: cargo.arg("--release"); } <del> if mode != Mode::Libstd && // FIXME(#45320) mode != Mode::Libtest && // FIXME(#45511) self.config.rust_codegen_units.is_none() && </del> <ins> if self.config.rust_codegen_units.is_none() && </ins> self.build.is_rust_llvm(compiler.host) { cargo.env("RUSTC_THINLTO", "1");

nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)


Question: cargo.arg("--release"); } <del> if mode != Mode::Libstd && // FIXME(#45320) mode != Mode::Libtest && // FIXME(#45511) self.config.rust_codegen_units.is_none() && </del> <ins> if self.config.rust_codegen_units.is_none() && </ins> self.build.is_rust_llvm(compiler.host) { cargo.env("RUSTC_THINLTO", "1");

cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.


Question: cargo.arg("--release"); } <del> if mode != Mode::Libstd && // FIXME(#45320) mode != Mode::Libtest && // FIXME(#45511) self.config.rust_codegen_units.is_none() && </del> <ins> if self.config.rust_codegen_units.is_none() && </ins> self.build.is_rust_llvm(compiler.host) { cargo.env("RUSTC_THINLTO", "1");

It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.


Question: cargo.arg("--release"); } <del> if mode != Mode::Libstd && // FIXME(#45320) mode != Mode::Libtest && // FIXME(#45511) self.config.rust_codegen_units.is_none() && </del> <ins> if self.config.rust_codegen_units.is_none() && </ins> self.build.is_rust_llvm(compiler.host) { cargo.env("RUSTC_THINLTO", "1");

I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!


Question: } impl Attribute { <ins> /// Returns `true` if the attribute's path matches the argument. If it matches, then the /// attribute is marked as used. /// /// To check the attribute name without marking it used, use the `path` field directly. </ins> pub fn check_name(&self, name: &str) -> bool { let matches = self.path == name; if matches {

Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .


Question: #![feature(const_fn)] #![feature(const_fn_union)] #![feature(const_generics)] <ins> #![cfg_attr(not(bootstrap), feature(const_ptr_offset_from))] #![cfg_attr(not(bootstrap), feature(const_type_name))] </ins> #![feature(custom_inner_attributes)] #![feature(decl_macro)] #![feature(doc_cfg)]

As shown in const-qualification can ignore some s, in the context of libcore / rustc crates: This should not compile without "miri unleashed"; const-qualification does not see this function as const since the unstable feature is not enabled, and thus does not check it. It outside of libcore, nor . cc More discussion is also available . I have a fix and will post a PR shortly. There are a couple of existing cases in where this matters (for and ), and I'll fix those at the same time.


Question: fn visit_foreign_item(&mut self, fi: &'tcx hir::ForeignItem) { if self.should_warn_about_foreign_item(fi) { <del> self.warn_dead_code(fi.id, fi.span, fi.name, fi.node.descriptive_variant()); </del> <ins> self.warn_dead_code(fi.id, fi.span, fi.name, fi.node.descriptive_variant(), "used"); </ins> } intravisit::walk_foreign_item(self, fi); } fn visit_struct_field(&mut self, field: &'tcx hir::StructField) { if self.should_warn_about_field(&field) { <del> self.warn_dead_code(field.id, field.span, field.name, "field"); </del> <ins> self.warn_dead_code(field.id, field.span, field.name, "field", "used"); </ins> } intravisit::walk_struct_field(self, field); }

I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.


Question: } _ => { let tt = TokenTree::Token(self.token.take()); <del> let is_joint = self.bump(); </del> <ins> let mut is_joint = self.bump(); if !self.token.is_op() { is_joint = NonJoint; } </ins> Ok((tt, is_joint)) } }

Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the


Question: version = "0.6.0" dependencies = [ "clippy_lints", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.0", </ins> "failure", "futures", "log", <del> "rand 0.6.1", </del> <ins> "rand 0.7.0", </ins> "rls-data", "rls-ipc", "serde",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.


Question: use std::env; use std::ffi::OsString; use std::fmt::Write as _; <del> use std::fs; </del> <ins> use std::fs::{self, File}; </ins> use std::io::{self, IsTerminal, Read, Write}; <del> use std::panic::{self, catch_unwind}; </del> <ins> use std::panic::{self, catch_unwind, PanicInfo}; </ins> use std::path::PathBuf; use std::process::{self, Command, Stdio}; use std::str;

slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.


Question: /// } /// ``` #[stable(feature = "io_error_inner", since = "1.3.0")] <ins> #[inline] </ins> pub fn get_mut(&mut self) -> Option<&mut (dyn error::Error + Send + Sync + 'static)> { match self.repr { Repr::Os(..) => None,

I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.


Question: } } <ins> /// If a tool does not pass its tests, don't ship it. /// Right now, we do this only for Miri. fn check_toolstate(&mut self) { let toolstates: Option<HashMap<String, String>> = File::open(self.input.join("toolstates-linux.json")).ok() .and_then(|f| serde_json::from_reader(&f).ok()); let toolstates = toolstates.unwrap_or_else(|| { println!("WARNING: `toolstates-linux.json` missing/malformed;  assuming all tools failed"); HashMap::default() // Use empty map if anything went wrong. }); // Mark some tools as missing based on toolstate. if toolstates.get("miri").map(|s| &*s as &str) != Some("test-pass") { println!("Miri tests are not passing, removing component"); self.miri_version = None; self.miri_git_commit_hash = None; } } </ins> /// Hash all files, compute their signatures, and collect the hashes in `self.digests`. fn digest_and_sign(&mut self) { for file in t!(self.input.read_dir()).map(|e| t!(e).path()) {

Looking at https://rust-, it seems like Miri is getting shipped as a rustup component even though the tests fail. Unfortunately, Miri is currently entirely usable, so it'd probably be better if it did not get shipped in this state. Is that something we can do? Cc
maybe we can make the miri toolstate always go to even if it technically is just
what would be the best place to change this? I think I'd prefer Miri not to be shipped at all when the tests fail; I'd rather people stick to an old-but-working Miri than to a new-but-broken one. I found but that does not seem to decide if a component gets built for distribution or not.
seems to suggest that it is supposed to work as you describe that it should be working. Since it obviously doesn't and I can't see how that comment could be true from looking at the source, I'm guessing this is some refactoring fallout. I'll dig a little into git blame
I found it. The comment was for rls in but then the code making the comment true was removed later
See for why this is hard to fix: the builders don't even run the tool tests, so they cannot know if the tests pass. :/ Also, that's probably for the better actually, as the "tools" builder sets --cfg miri to be more Miri-friendly and we don't want that in the release artifacts.
One (crazy?) thing we could so is have the dist builders query the toolstate repo to figure out if the tests are passing...
That will either retrieve an outdated toolstate or will need to block until the toolstate is uploaded ...
Without blocking it would lag behind by 1 merged PR, yes.
would it be possible to add some kind of build assert so Miri fails on builders when Rust internals change too much?
Well builders already know when Miri fails to build because internals change too much. The issue is things that make Miri still compile but break the test suite.
would it be possible to at least change the logic that opens issues such that for Miri, it opens an issue like when the tests fail? I could also try to implement that if you point me to the right place. So far we have had zero cases of Miri tests spuriously failing.


Question: } } <ins> /// If a tool does not pass its tests, don't ship it. /// Right now, we do this only for Miri. fn check_toolstate(&mut self) { let toolstates: Option<HashMap<String, String>> = File::open(self.input.join("toolstates-linux.json")).ok() .and_then(|f| serde_json::from_reader(&f).ok()); let toolstates = toolstates.unwrap_or_else(|| { println!("WARNING: `toolstates-linux.json` missing/malformed;  assuming all tools failed"); HashMap::default() // Use empty map if anything went wrong. }); // Mark some tools as missing based on toolstate. if toolstates.get("miri").map(|s| &*s as &str) != Some("test-pass") { println!("Miri tests are not passing, removing component"); self.miri_version = None; self.miri_git_commit_hash = None; } } </ins> /// Hash all files, compute their signatures, and collect the hashes in `self.digests`. fn digest_and_sign(&mut self) { for file in t!(self.input.read_dir()).map(|e| t!(e).path()) {

That should be easy to do:
Gave it a shot at
had an interesting idea: can't we do the "don't ship broken tools" as part of a post-processing step? We anyway do some little amount of work when a commit hits (as opposed to ), such as actually updating the toolstate repo. So maybe that could also either delete the broken components from the S3 bucket, or else generate a file to be put into the S3 bucket that says which of the components are really there so that the broken ones can be considered "not there"? do you think something like that would be possible?
Thinking about this again, probably the most natural place to do this is in the . That could "just" also check the toolstate database for the commit it is promoting, and then (possibly only for certain tools) not add them to the nightly if their toolstate is not green.
This is biting us again right now, where CI knows that Miri is broken but we ship the component anyway, leading to CI failures in downstream projects that have Miri in their CI.
For another case where this issue got quite painful, see
My PR is because I was incorrectly assuming that all commits have their toolstate recorded in the toolstate repo. Reopening.
FTR, for testing , I downloaded some artifacts: then I edited my : and finally I ran This produces stuff in .
So looks like we have logic in that specifically does not commit to the toolstate repo if nothing changed: Unfortunately, this means that we cannot easily fetch the toolstate of the to-be-produced release in build-manifest, which caused my to fail. Would it be okay for you to change this logic to record the toolstate of all commits in the toolstate repo? Or would you prefer if I try to find another approach for solving this issue? Right now I am somewhat out of ideas though if we cannot even use the toolstate repo to communicate this information.
Wouldn't it be simpler to save list of "good" components to something like and upload it alongside tarballs? Running would show what you need.
I guess we could upload the two JSON files from the two tool runners somehow? Not sure which would be the right places to hook for that, though.
Status: blocked on which is blocked on
This seems to be finally fixed!


Question: } } <ins> /// If a tool does not pass its tests, don't ship it. /// Right now, we do this only for Miri. fn check_toolstate(&mut self) { let toolstates: Option<HashMap<String, String>> = File::open(self.input.join("toolstates-linux.json")).ok() .and_then(|f| serde_json::from_reader(&f).ok()); let toolstates = toolstates.unwrap_or_else(|| { println!("WARNING: `toolstates-linux.json` missing/malformed;  assuming all tools failed"); HashMap::default() // Use empty map if anything went wrong. }); // Mark some tools as missing based on toolstate. if toolstates.get("miri").map(|s| &*s as &str) != Some("test-pass") { println!("Miri tests are not passing, removing component"); self.miri_version = None; self.miri_git_commit_hash = None; } } </ins> /// Hash all files, compute their signatures, and collect the hashes in `self.digests`. fn digest_and_sign(&mut self) { for file in t!(self.input.read_dir()).map(|e| t!(e).path()) {

Today nightly was shipped with , and everything looks normal :tada:
Miri is "test-fail" now, so with the next nightly we should be able to see if indeed it gets removed from rustup as it should.
Confirmed it's working! On miri is missing.


Question: <ins> //@ edition: 2021 #![feature(must_not_suspend, allocator_api)] #![deny(must_not_suspend)] use std::alloc::*; use std::ptr::NonNull; #[must_not_suspend] struct MyAllocatorWhichMustNotSuspend; unsafe impl Allocator for MyAllocatorWhichMustNotSuspend { fn allocate(&self, l: Layout) -> Result<NonNull<[u8]>, AllocError> { Global.allocate(l) } unsafe fn deallocate(&self, p: NonNull<u8>, l: Layout) { Global.deallocate(p, l) } } async fn suspend() {} async fn foo() { let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); //~^ ERROR allocator `MyAllocatorWhichMustNotSuspend` held across a suspend point, but should not be suspend().await; drop(x); } fn main() {} </ins>

This code here has a potential issue: If the Box has a custom allocator, then that will not be checked at all. So whatever is used for, it ignores anything stored in custom allocators. It seems like this is just for a lint, so this is probably not critical, but I guess should still be fixed. Cc -- not sure whom else to ping for coroutine state machine transform things?
Cc (also a regular occurrence in this file's )
Lol sorry, I thought I had clicked enter on a comment but I must've not. Let me rewrite it. Yeah, this is approximately the level of urgency you determined. This code exists for an unstable lint, . I don't expect people to be writing , but technically they could.


Question: self.with_context(LabeledBlock, |v| v.visit_block(&b)); } hir::ExprBreak(label, ref opt_expr) => { <ins> opt_expr.as_ref().map(|e| self.visit_expr(e)); </ins> if self.require_label_in_labeled_block(e.span, &label, "break") { // If we emitted an error about an unlabeled break in a labeled // block, we don't need any further checking for this break any more

Input: Output: This is on commit .
I've edited that code just recently so would want to work on this
Made PR to fix this
Thanks for fixing this :-) I also reported a couple of other looping-related bugs in in case you also want to have a look at those.
wow those are quite nice bugs :p. Will have a look.


Question: <ins> // error-pattern: aborting due to 6 previous errors fn i(n{...,f # </ins>

I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
The only early return I see that doesn't emit is here:
Applying the most obvious patch, I get the following non-ICE output: The "expected , found " bit doesn't seem quite right. :slightlysmilingface:
is an unfortunate side effect of the unmatched delimiter recovery logic not accounting for s. Submit a PR with this patch to fix this ICE as fixing the slightly misleading message will require a much larger (unrelated) change.
I'll toss one up after I finish running the test suite. One thing: I'm not sure how to annotate the test. It looks like there's four errors that all point to EOF, but whatever I try to write, only one of them gets recognized as referring to that line.
this is what I did


Question: <ins> error[E0425]: cannot find function `missing` in this scope --> $DIR/error-body.rs:5:5 | LL |     missing(); |     ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

<!-- ICE: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )


Question: <ins> error[E0425]: cannot find function `missing` in this scope --> $DIR/error-body.rs:5:5 | LL |     missing(); |     ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: let msg = "asm template must be a string literal"; let template_sp = template_expr.span; <ins> let template_is_mac_call = matches!(template_expr.kind, ast::ExprKind::MacCall(_)); </ins> let (template_str, template_style, template_span) = { let ExpandResult::Ready(mac) = expr_to_spanned_string(ecx, template_expr, msg) else { return ExpandResult::Retry(());

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to


Question: return } <ins> // Package save-analysis from stage1 if not doing a full bootstrap, as the // stage2 artifacts is simply copied from stage1 in that case. let compiler = if build.force_use_stage1(compiler, target) { Compiler::new(1, compiler.host) } else { compiler.clone() }; </ins> let name = format!("rust-analysis-{}", package_vers(build)); let image = tmpdir(build).join(format!("{}-{}-image", name, target)); <del> let src = build.stage_out(compiler, Mode::Libstd).join(target).join("release").join("deps"); </del> <ins> let src = build.stage_out(&compiler, Mode::Libstd).join(target).join("release").join("deps"); </ins> let image_src = src.join("save-analysis"); let dst = image.join("lib/rustlib").join(target).join("analysis");

So invalidated the assumption that the final stage is stage2, but [this piece of code][] still thought so, so the save-analysis data is never generated. This enraged the bots. Let's polish rustbuild with some more <3 so that we could have a fresh nightly for a nice New Year gift to everyone... []:
BTW the failure on the win32 beta bot (ouch!) is not related to this. It's most likely a Windows hiccup.
Ahhhh big failure of mine. I'm focusing on the generation part (the envvar) and forgot to touch the logic too, and the bots are as red as yesterday (facepalm). Trying to hit the 2017-01-02 nightly instead...


Question: version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.


Question: version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs


Question: [[package]] name = "rand" <del> version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "fuchsia-cprng 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "rdrand 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rand" </del> version = "0.6.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [

I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.


Question: [[package]] name = "rand" <del> version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "fuchsia-cprng 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "rdrand 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rand" </del> version = "0.6.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [

That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps


Question: return value else: return "'" + value + "'" <ins> elif isinstance(value, dict): return "{" + ", ".join(map(lambda a: "{} = {}".format(to_toml(a[0]), to_toml(a[1])), value.items())) + "}" </ins> else: raise RuntimeError('no toml')

I tried this code: I expected to see this happen: generates a toml file with the contents Instead, this happened: HEAD is branched from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Relevant code:
claim
Error: Parsing assign command in failed: ...' claim' ' :)'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have a PR ready but I need to wait for to get merged since that PR was and creating a new branch now doesn't help
You can run (replace with the name of the rust-lang remote), then run . In the future, take the habit of always having your branch fast-forward able, it will avoid you hassles with the GitHub UI.
That worked for me, Thank you so much!


Question: adjusted_ty, index_ty); <del> // First, try built-in indexing. match (adjusted_ty.builtin_index(), &index_ty.sty) { (Some(ty), &ty::TyUint(ast::UintTy::Usize)) | (Some(ty), &ty::TyInfer(ty::IntVar(_))) => { debug!("try_index_step: success, using built-in indexing"); let adjustments = autoderef.adjust_steps(lvalue_pref); self.apply_adjustments(base_expr, adjustments); return Some((self.tcx.types.usize, ty)); } _ => {} } </del> for &unsize in &[false, true] { let mut self_ty = adjusted_ty; if unsize {

Hello, today we've found some weird behaviour of array indexing. Here is the Code snippet: The question is, why is the indexing operator behaves depending on whether we evaluate in place or not.
Highly related question :
Moreover, does not compile too.
points to this being a difference in how builtin indexing works vs overloaded indexing. My cleaned up version of the transcript: Highly related to , which will cause these types of situations to occur more frequently.
As a workaround, you can write an explicit type of which will then allow builtin indexing to happen:


Question: adjusted_ty, index_ty); <del> // First, try built-in indexing. match (adjusted_ty.builtin_index(), &index_ty.sty) { (Some(ty), &ty::TyUint(ast::UintTy::Usize)) | (Some(ty), &ty::TyInfer(ty::IntVar(_))) => { debug!("try_index_step: success, using built-in indexing"); let adjustments = autoderef.adjust_steps(lvalue_pref); self.apply_adjustments(base_expr, adjustments); return Some((self.tcx.types.usize, ty)); } _ => {} } </del> for &unsize in &[false, true] { let mut self_ty = adjusted_ty; if unsize {

It appears that when it's not obvious the index type is , we fall back to overloaded indexing: Fails in constant checking, : And also with the new MIR-based constant checker, :


Question: } fn parse_borrowed_pointee(&mut self) -> PResult<'a, TyKind> { <del> let opt_lifetime = if self.check_lifetime() { Some(self.expect_lifetime()) } else { None }; </del> <ins> let and_span = self.prev_token.span; let mut opt_lifetime = if self.check_lifetime() { Some(self.expect_lifetime()) } else { None }; </ins> let mutbl = self.parse_mutability(); <ins> if self.token.is_lifetime() && mutbl == Mutability::Mut && opt_lifetime.is_none() { // A lifetime is invalid here: it would be part of a bare trait bound, which requires // it to be followed by a plus, but we disallow plus in the pointee type. // So we can handle this case as an error here, and suggest `'a mut`. // If there *is* a plus next though, handling the error later provides better suggestions // (like adding parentheses) if !self.look_ahead(1, |t| t.is_like_plus()) { let lifetime_span = self.token.span; let span = and_span.to(lifetime_span); let mut err = self.struct_span_err(span, "lifetime must precede `mut`"); if let Ok(lifetime_src) = self.span_to_snippet(lifetime_span) { err.span_suggestion( span, "place the lifetime before `mut`", format!("&{} mut", lifetime_src), Applicability::MaybeIncorrect, ); } err.emit(); opt_lifetime = Some(self.expect_lifetime()); } } </ins> let ty = self.parse_ty_no_plus()?; Ok(TyKind::Rptr(opt_lifetime, MutTy { ty, mutbl })) }

Expected result: a diagnostic suggests placing before Actual diagnostic output: <details</details
Output from rustc 1.43 (): The size of the output appears to be a recent regression.
: searched nightlies: from nightly-2020-03-09 to nightly-2020-06-21 regressed nightly: nightly-2020-03-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Further testing confirms , specifically  introduced the large number of diagnostics.
Assigning .


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search


Question: # (to avoid spending a lot of time cloning llvm) if [ "$EXTERNAL_LLVM" = "" ]; then RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --set build.optimized-compiler-builtins" <ins> # Likewise, only demand we test all LLVM components if we know we built LLVM with them export COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS=1 </ins> elif [ "$DEPLOY$DEPLOY_ALT" = "1" ]; then echo "error: dist builds should always use optimized compiler-rt!" >&2 exit 1

In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.


Question: [true] `{$param_name}` *[false] `fn` parameter } has {$lifetime_kind -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` } but calling `{assoc_item}` introduces an implicit `'static` lifetime requirement </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` } but calling `{$assoc_item}` introduces an implicit `'static` lifetime requirement </ins> .label1 = {$has_lifetime -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` </ins> } .label2 = ...is used and required to live as long as `'static` here because of an implicit lifetime bound on the {$has_impl_path -> <del> [named] `impl` of `{$impl_path}` *[anon] inherent `impl` </del> <ins> [true] `impl` of `{$impl_path}` *[false] inherent `impl` </ins> } infer_but_needs_to_satisfy = {$has_param_name -> [true] `{$param_name}` *[false] `fn` parameter } has {$has_lifetime -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` </ins> } but it needs to satisfy a `'static` lifetime requirement .influencer = this data with {$has_lifetime -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` </ins> }... .require = {$spans_empty -> *[true] ...is used and required to live as long as `'static` here

[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :


Question: } } <ins> const LOADERS: &Vec<&'static u8> = &Vec::new(); pub fn break_code() -> Option<&'static u8> { for loader in &*LOADERS { //~ ERROR cannot move out of a shared reference return Some(loader); } None } </ins> fn main() {}

<!-- 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. --Haven't minimized the code yet, but the exact code is up here: It's a kind of search algorithm. I think the problematic code is the function in . Will report back if I figure out anything more. <!-- 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</detailsI just switched to the stable toolchain, and the compilar gave me two errors: Apparently these were not caught by the nightly compiler.
This is probably a duplicate of You're using the nightly compiler though, so working as intended
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: } } <ins> const LOADERS: &Vec<&'static u8> = &Vec::new(); pub fn break_code() -> Option<&'static u8> { for loader in &*LOADERS { //~ ERROR cannot move out of a shared reference return Some(loader); } None } </ins> fn main() {}

<!-- 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. --Compiles with replaced for <!-- 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 --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high


Question: ArenaSet(vec![], &Z) } unsafe { <del> use std::sync::{Once, ONCE_INIT}; </del> <ins> use std::sync::Once; </ins> fn require_sync<T: Sync>(_: &T) { } unsafe fn __stability() -> &'static ArenaSet<Vec<u8>> { use std::mem::transmute; static mut DATA: *const ArenaSet<Vec<u8>> = 0 as *const ArenaSet<Vec<u8>>; <del> static mut ONCE: Once = ONCE_INIT; </del> <ins> static mut ONCE: Once = Once::new(); </ins> ONCE.call_once(|| { DATA = transmute ::<Box<ArenaSet<Vec<u8>>>, *const ArenaSet<Vec<u8>>>

, anyone using the former . I guess we can't outright deprecate given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use instead"). This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.
Can we just deprecate it?
Why is a problem?
Similarly, the initializers for the family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the function. For example, see .
"There should be only one way of doing it" I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of 's backwards compatibility policy, behavior, and release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things" across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today
/me Prepares plans to deprecate :) In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way. Seems fine.
We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were . I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!
was stabilized . Didn't find any reference to it .
Was it callable as a const fn in 1.2.0?
The const-ness was made stable in the same PR as for AtomicUsize::new:


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that we don't ICE due to encountering unsubstituted type // parameters when untupling FnOnce parameters during translation of // an unboxing shim. #![feature(unboxed_closures)] fn main() { let _: Box<FnOnce<(),()>> = box move |&mut:| {}; } </ins>

Looks like substitutions weren't being applied in all places, resulting in it choking on an unsubstituted type parameter. The fix should hopefully be easy.


Question: <ins> error: `#[panic_handler]` function required, but not found error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:28:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `core::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `core::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:33:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `core::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `core::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:38:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `core::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `core::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:43:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `core::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `core::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:48:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `core::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `core::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:53:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `core::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `core::ops::RangeToInclusive<{integer}>` error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

is an incorrect suggestion because has higher precedence than . It should suggest .
If someone wants to tackle this issue, it should be straightforward to fix. In: there should be another branch for , where the path of the call is . This code is a good reference: This issue affects the other range syntaxes too, so those should also be fixed (although these are not — look at for clues).
Hi I'd like to tackle this and take the plunge into the Rust compiler code :)
great! Let me know if you hit any snags or need any more tips. You'll want to add tests for these (in ). The is a good place for general information about the compiler. When you're done, include in the pull request and I'll review it!
you've anticipated most of my newbie questions already :) Thanks for that info, very useful! I'm now in the process of stressing my PC with lots of compiling to actually get started. Skimming the test code I'm really impressed by how easy it is to add "UI" tests for these sorts of things (compile this, expect this error on this line). Snazzy! That's all great, but do you anticipate I should also add "deeper" tests? I guess I'm trying to understand if the scope of this is just pure UI or do I need to touch some syntax parsing/immediate representations, since you mentioned code in . Because the compiler is emitting a syntax suggestion, we might want to assert that the suggestion is correct syntax in the first place. I don't know if that's how deep the rabbit hole goes and if there's a facility to help out, but my hunch is that since we have all of the compiler at hand, why not use it to validate the suggestion syntax? EDIT: OK, reading up on adding new tests to the compiler I encountered mention of , and it seems to be sort-of what I was after.
The issue here is just a diagnostic issue, so checking that we're getting the updated hint is enough. The code in is just helpful to see what ranges like and are desugared into, so you can catch them in — you shouldn't need to modify anything (apart from the test) outside of . It would technically be possible to do something like this, but it would probably be more trouble than it's worth.