Question: needlesArr.iter().fold(|x, y| { }); //~^^ ERROR this function takes 2 parameters but 1 parameter was supplied <del> //~^^^ NOTE the following parameter types were expected // </del> <ins> //~| NOTE the following parameter types were expected //~| NOTE expected 2 parameters </ins> // the first error is, um, non-ideal. }

From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.


Question: // of a macro that is not vendored by Rust and included in the toolchain. // See https://github.com/rust-analyzer/rust-analyzer/issues/6038. <ins> // On certain platforms right now the "main modules" modules that are // documented don't compile (missing things in `libc` which is empty), // so just omit them with an empty module and add the "unstable" attribute. // Unix, linux, wasi and windows are handled a bit differently. </ins> #[cfg(all( doc, <del> not(any( </del> <ins> any( </ins> all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") <del> )) </del> <ins> ) </ins> ))] <del> #[path = "."] mod doc { // When documenting std we want to show the `unix`, `windows`, `linux` and `wasi` // modules as these are the "main modules" that are used across platforms, // so these modules are enabled when `cfg(doc)` is set. // This should help show platform-specific functionality in a hopefully cross-platform // way in the documentation. pub mod unix; pub mod linux; pub mod wasi; pub mod windows; } </del> <ins> #[unstable(issue = "none", feature = "std_internals")] pub mod unix {} </ins> #[cfg(all( doc, any(

More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .


Question: None); // If the item has the name of a field, give a help note <del> if let (&ty::TyStruct(did, _), Some(_)) = (&rcvr_ty.sty, rcvr_expr) { </del> <ins> if let (&ty::TyStruct(did, substs), Some(expr)) = (&rcvr_ty.sty, rcvr_expr) { </ins> let fields = ty::lookup_struct_fields(cx, did); <del> if fields.iter().any(|f| f.name == item_name) { cx.sess.span_note(span, &format!("use `(s.{0})(...)` if you meant to call the  function stored in the `{0}` field", item_name)); </del> <ins> if let Some(field) = fields.iter().find(|f| f.name == item_name) { let expr_string = match cx.sess.codemap().span_to_snippet(expr.span) { Ok(expr_string) => expr_string, _ => "s".into() // Default to a generic placeholder for the // expression when we can't generate a string // snippet }; let span_stored_function = || { cx.sess.span_note(span, &format!("use `({0}.{1})(...)` if you meant to call  the function stored in the `{1}` field", expr_string, item_name)); }; let span_did_you_mean = || { cx.sess.span_note(span, &format!("did you mean to write `{0}.{1}`?", expr_string, item_name)); }; // Determine if the field can be used as a function in some way let field_ty = ty::lookup_field_type(cx, did, field.id, substs); if let Ok(fn_once_trait_did) = cx.lang_items.require(FnOnceTraitLangItem) { let infcx = fcx.infcx(); infcx.probe(|_| { let fn_once_substs = Substs::new_trait(vec![infcx.next_ty_var()], Vec::new(), field_ty); let trait_ref = ty::TraitRef::new(fn_once_trait_did, cx.mk_substs(fn_once_substs)); let poly_trait_ref = trait_ref.to_poly_trait_ref(); let obligation = Obligation::misc(span, fcx.body_id, poly_trait_ref.as_predicate()); let mut selcx = SelectionContext::new(infcx, fcx); if selcx.evaluate_obligation(&obligation) { span_stored_function(); } else { span_did_you_mean(); } }); } else { match field_ty.sty { // fallback to matching a closure or function pointer ty::TyClosure(..) | ty::TyBareFn(..) => span_stored_function(), _ => span_did_you_mean(), } } </ins> } }

I forget if there's already a bug on this, but it would be nice if, when you wrote and doesn't have a field named , but does have a nullary method named , the compiler gave a hint like "did you mean to write ?" It could also do vice versa (if you write A.B()ABA.B?) I ran into this in trans, where I have frequently written instead of .
Test: The error message is better now than it was: in that it suggests there is a method named . But it could still be improved. (The intention may not have been to take the method's value; it seems more likely that the programmer thought it wasn't a method at all.)
My previous comment still holds. It would be great if you would see the "try writing an anonymous function" hint for something like and instead see a "did you mean to write ?" in situations like this one.
I'd also like to see one when trying to call a function-typed struct field: emits Foof. It'd be nice if it tried to see if it could auto-deref to a struct field, and if so, say (f.f)().
A nice idea. Assigning P-low.
Currently gives which is pretty close to the proposed behavior. Replacing the wih yields the same as before (i.e. does not suggest removing the ):
Updated the example gives: which now prints It's nice that the note is there, but the text is suboptimal: isn't a function.
I'm working on a fix for this, but I'm struggling with the final portion. With this code: I get the output: My current changes are . I'm not sure if it's possible to have the output say "" and "kitty.x" with the input to the function. Any ideas? Or should I just keep the message in the same format as it is now and output "s.func" and "did you mean to write ?"? Edit: Ideally, I would like to output: I'm wondering if that's at all possible, especially because instead of , there might be an expression.
I got around that error message. Now I'm making sure the previous message is displayed under the proper circumstances.


Question: debug!("overloaded_deref_ty({:?})", ty); let tcx = self.infcx.tcx; <ins> if ty.references_error() { return None; } </ins> // <ty as Deref> let trait_ref = ty::TraitRef::new(tcx, tcx.lang_items().deref_trait()?, [ty]); let cause = traits::ObligationCause::misc(self.span, self.body_id);

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc


Question: /// impl Gadget { ///     /// Construct a reference counted Gadget. ///     fn new() -> Arc<Self> { <del> ///         Arc::new_cyclic(|me| Gadget { me: me.clone() }) </del> <ins> ///         // `me` is a `Weak<Gadget>` pointing at the new allocation of the ///         // `Arc` we're constructing. ///         Arc::new_cyclic(|me| { ///             // Create the actual struct here. ///             Gadget { me: me.clone() } ///         }) </ins> ///     } /// ///     /// Return a reference counted pointer to Self.

As I in the i.r-l.o prerelease thread, the documentation of the new(ly stabilized) and method could really use some elaboration before the 1.60 release. I'm quite familiar with refcounting, strong/weak refs, etc. but just from the doc, I have no idea what problem the new method solves exactly, when I should use it, why the closure is needed, how the closure argument seems to come from "thin air", and what the closure should return.
Argh, thanks. Could've sworn I specifically double-checked that I wrote "cyclic"…
Problem the method solves: constructing a which holds a pointer to itself. When you should use it: when you need to do the above. Previously you'd construct with e.g. and then mutate the value (via e.g. ) to fix up the self references. Where the closure argument comes from: essentially, the point of is that the place is allocated first, with strong=0, weak=1. The place has no data yet (you're constructing the value to place there), but is in the "zombie" state where it has weak references but no data. Why the closure is needed: the place needs to be "finished" once the value is created. In theory, you could "recover" any zombie weak, but for the most case, Rust wants to pretend that a "zombie" and a dangling are equivalent. What the closure should return: the closure returns the object to place in the reference counted place. After you've constructed the object, the reference count is "activated" and the object is accessable by (clones of) the weak pointer given to the constructor closure. For the most part, exists to construct style objects more easily, which is what the example demonstrates. It can be used for other use cases, but this is the primary motivating example. I'm biased because I know what is used for, so the existing documentation is enough. The docs aren't going to be changed for 1.60, but if you (or anyone) can improve the docs (with the above information or otherwise), PRs to do so are welcome!
I agree I had to read the documentation a few times to understand what this does.
Hi!


Question: /// impl Gadget { ///     /// Construct a reference counted Gadget. ///     fn new() -> Arc<Self> { <del> ///         Arc::new_cyclic(|me| Gadget { me: me.clone() }) </del> <ins> ///         // `me` is a `Weak<Gadget>` pointing at the new allocation of the ///         // `Arc` we're constructing. ///         Arc::new_cyclic(|me| { ///             // Create the actual struct here. ///             Gadget { me: me.clone() } ///         }) </ins> ///     } /// ///     /// Return a reference counted pointer to Self.

Just a quick note that changing the documentation for the Rust 1.60.0 release itself will likely not be possible, that'd require a full release rebuild.
I'm sending a PR with explanations provided by so that it'll at least be in the next release. Why do you need a full release rebuild btw? Isn't it possible to regen the docs without rebuilding everything like the option on rustc?
I opened Feedback is very welcome. :)
Our release tooling only supports building everything at the same time.
Well, at least it'll be present in the next release with a beta backport.


Question: <ins> // check-pass pub struct Bar<'a>(&'a Self) where Self: ; fn main() {} </ins>

Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).


Question: fn f() -> bool { let c = false; <del> if(c) { </del> <ins> if(c) { //~ ERROR unnecessary parentheses </ins> println!("next"); } <del> if (c){ </del> <ins> if (c){ //~ ERROR unnecessary parentheses </ins> println!("prev"); } while (false && true){ <del> if (c) { </del> <ins> if (c) { //~ ERROR unnecessary parentheses </ins> println!("norm"); } } <del> while(true && false) { for _ in (0 .. 3){ </del> <ins> while(true && false) { //~ ERROR unnecessary parentheses for _ in (0 .. 3){ //~ ERROR unnecessary parentheses </ins> println!("e~") } } <del> for _ in (0 .. 3) { while (true && false) { </del> <ins> for _ in (0 .. 3) { //~ ERROR unnecessary parentheses while (true && false) { //~ ERROR unnecessary parentheses </ins> println!("e~") } }

Update test file to use + annotations instead of (see https://rust-) The files need to update are: - <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
is the correct file name , not ? And what about this comment?
Is the problem fixed ? If not, I would like to work on it !
WIP PR has been closed due to inactivity so you can work on this.
I would like to be assigned to this issue. Am I supposed to do a new pull request ?
claim Go ahead!
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
Hmm, it's odd, anyway, you can assign the issue to yourself by comment Ah, I mistaken the command, the collect one is , sorry.
claim
If I understood well the problem: I must replace all the by just , even if comment exist ? Because the output changes, I should modify the .stderr version I must change with in , and as should raise an error we add why add in the version ?


Question: <ins> // Copyright 2018 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. // ignore-cloudabi no processes // ignore-emscripten no processes use std::io::ErrorKind; use std::process::Command; fn main() { assert_eq!(Command::new("nonexistent") .spawn() .unwrap_err() .kind(), ErrorKind::NotFound); } </ins>

When confusing a Fn-like struct with a regular struct in an pattern, the output leaves a lot to be desired: <details<summary<a href=""Current output</a</summary</detailsWe should probably collect all these errors into a single diagnostic error: Even better if there was only one diagnostic.


Question: } match kind { AstFragmentKind::Pat if macro_ident.name == sym::vec => { <del> let mut suggestion = None; if let Ok(code) = parser.sess.source_map().span_to_snippet(site_span) { if let Some(bang) = code.find('!') { suggestion = Some(code[bang + 1..].to_string()); } } if let Some(suggestion) = suggestion { e.span_suggestion( site_span, "use a slice pattern here instead", suggestion, Applicability::MachineApplicable, ); } else { e.span_label( site_span, "use a slice pattern here instead", ); } e.help("for more information, see https://doc.rust-lang.org/edition-guide/ rust-2018/slice-patterns.html"); </del> <ins> suggest_slice_pat(&mut e, site_span, parser); </ins> } _ => annotate_err_with_kind(&mut e, kind, site_span), };

The idea of shortening to has been discussed many times before, and the general consensus always ends up being that it is not a good idea. I would like to propose something a bit different, so please hear me out. I propose that instead of aliasing to , we instead just make expand into when in the context of a variable declaration. For example: This solves the problems (readability, more concise) that people have with , whilst not causing the issues that people have (pattern matching and consistancy). The most common issue people have with aliasing to is that it doesn't fit well with patterns, like . However, gets rid of this problem, because you wouldn't write if you were trying to pattern match, so why would someone want to write ? You wouldn't do that, and it wouldn't compile. This would be optional, of course. would still work fine, and people would just have to option of removing the to let it be implied. There are a lot of other abbreviations used in rust (, , ) that all serve the purpose of writing less. It just doesn't feel right that one of the most commonly used keywords is so long. :heart::crab: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Rust wants to make to make you think when you try and use mutation, even if only a little bit, because mutation can be difficult to reason about. Shortening to doesn't fit this philosophy. Also, this makes mutation just as easy as no mutation. This will lead people to choose mutation because it will give them less compiler errors in the short term, and in doing so open themselves up to some weird bugs that could have been prevented with the syntactic salt that is . tldr: wasn't rejected because of the name , but because it allowed easy mutation, which runs counter to Rust's philosophy.
I politely disagree. In fact, it is actually the other way around. Using unnecessarily will cause compiler warnings, discouraging the use of unneeded mutability. The compiler doesn't warn when the use of is actually needed.
The fact that people will choose in the face of compiler warnings has been shown in practice, across many projects.


Question: } match kind { AstFragmentKind::Pat if macro_ident.name == sym::vec => { <del> let mut suggestion = None; if let Ok(code) = parser.sess.source_map().span_to_snippet(site_span) { if let Some(bang) = code.find('!') { suggestion = Some(code[bang + 1..].to_string()); } } if let Some(suggestion) = suggestion { e.span_suggestion( site_span, "use a slice pattern here instead", suggestion, Applicability::MachineApplicable, ); } else { e.span_label( site_span, "use a slice pattern here instead", ); } e.help("for more information, see https://doc.rust-lang.org/edition-guide/ rust-2018/slice-patterns.html"); </del> <ins> suggest_slice_pat(&mut e, site_span, parser); </ins> } _ => annotate_err_with_kind(&mut e, kind, site_span), };

Also, the problem isn't that people may choose to put just for the heck of it, but that they will unintentionally mutate something that was supposed to be immutable. And because it is being mutated, there is no warning, and they used because it is their default, it is their default because it gets rid of compiler errors that say they were trying to mutate things that are immutable even though they weren't supposed to mutate them in the first place. They will use because it is just as easy as making it immutable. So the problem is a bit more subtle than you seem to think.
Incorrect. Extreme brevity harms readability. See Perl. lol Readers would ignore the vs distinction far more often that vs , partially due to length difference, but works even better than say . It's true boilerplate often harms readability, but boilerplate requires some complexity be repeated, not merely the in . It harms readability even further if also works for , especially when you consider code readers need not actually know Rust. Rust syntax was designed largely to reduce cognitive load, not to reduce typing. We use , , and , not any shorter alternatives. And delegation RFCs have kinda given up the short syntaxes. I think Rust's omission of is now considered a mistake, but presumably helps C programmers. Rust has short keywords only really for fundamental "items" used repeatedly by basically every module. It's similar cognitive load if you write , , or , but actually just writing the shorter bare increases cognitive load. I think invokes the minor linguistic subtlety that variable means mutable binding, while acts like a common term for binding, which makes very slightly clearer.
The statement would be orthogonal to the current language in some sense though. is not a special syntax, but is composed of statement + pattern. It is in line with other places expects a pattern, where you can write , , or .
It seems unlikely to me that we would support as a short-hand. I'm personally opposed to it both because it adds unnecessary compiler complexity, stylistic schisms, and for the reasons outlined by However, I've taken the liberty of reusing this issue towards improved diagnostics: The idea here is to check . The idea here is to check: The relevant code is here: cc
claim
Error: Parsing assign command in failed: claim :)... Please let know if you're having trouble with this bot.


Question: } match kind { AstFragmentKind::Pat if macro_ident.name == sym::vec => { <del> let mut suggestion = None; if let Ok(code) = parser.sess.source_map().span_to_snippet(site_span) { if let Some(bang) = code.find('!') { suggestion = Some(code[bang + 1..].to_string()); } } if let Some(suggestion) = suggestion { e.span_suggestion( site_span, "use a slice pattern here instead", suggestion, Applicability::MachineApplicable, ); } else { e.span_label( site_span, "use a slice pattern here instead", ); } e.help("for more information, see https://doc.rust-lang.org/edition-guide/ rust-2018/slice-patterns.html"); </del> <ins> suggest_slice_pat(&mut e, site_span, parser); </ins> } _ => annotate_err_with_kind(&mut e, kind, site_span), };

Although I would also guess that the initial idea is very unlikely to end up accepted, it feels premature to unilaterally hijack the thread in your very first comment and make it have a different (and in a way opposite) purpose. Teams of the Rust project are designed to make decisions collectively. Improving diagnostics sounds good, but issue numbers are cheap.
Implementing something as a diagnostic actually brings you closer to a working implementation -- I think more proposals should start out as diagnostics. I will not bother the other language team members with not-fully-formed proposals that we will not accept in either case. I converted the issue into the most actionable and productive thing it could be. The place for ephemeral discussions is either on Discord or on internals. If you want to discuss this further, I'm available at Discord (but will not respond to it further here). wasting everyone's time with things that will go nowhere (because it won't be accepted and because it is not important enough to be raised at the team) is not.
IMHO, the original thing this issue was opened for should be an RFC, not an issue. I'd have closed this, pointed the OP to the RFCs repo, and opened a new issue for the diagnostic issue.
This issue was literally in the RFCs repo initially, transferred it from there.
Language bashing is not welcome here
Wait, so should I unassign here, and assign to the new issue?
Nah, just use this one.
Yeah, thats fine. You can just change this issue to be for diagnostics instead.
I'm sorry, I've been pretty busy with coursework, and I'm still fighting my Python installation to even build the compiler, let alone make progress on this. Sorry :(
I'll assign this to myself to work on when I have time. If you want to work on it however, feel free to work-steal it from me!
I would like to help with this
Sorry; should have updated this issue...! There's a PR at the moment. Feel free to leave suggestions on it if you like. :)


Question: } match kind { AstFragmentKind::Pat if macro_ident.name == sym::vec => { <del> let mut suggestion = None; if let Ok(code) = parser.sess.source_map().span_to_snippet(site_span) { if let Some(bang) = code.find('!') { suggestion = Some(code[bang + 1..].to_string()); } } if let Some(suggestion) = suggestion { e.span_suggestion( site_span, "use a slice pattern here instead", suggestion, Applicability::MachineApplicable, ); } else { e.span_label( site_span, "use a slice pattern here instead", ); } e.help("for more information, see https://doc.rust-lang.org/edition-guide/ rust-2018/slice-patterns.html"); </del> <ins> suggest_slice_pat(&mut e, site_span, parser); </ins> } _ => annotate_err_with_kind(&mut e, kind, site_span), };

From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.


Question: debug!("region_bound: {:?}", region_bound); <del> ty::sort_bounds_list(&mut projection_bounds); ty::ExistentialBounds { region_bound: region_bound, builtin_bounds: builtin_bounds, projection_bounds: projection_bounds, } </del> <ins> ty::ExistentialBounds::new(region_bound, builtin_bounds, projection_bounds) </ins> } /// Given the bounds on an object, determines what single region bound

It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).


Question: debug!("region_bound: {:?}", region_bound); <del> ty::sort_bounds_list(&mut projection_bounds); ty::ExistentialBounds { region_bound: region_bound, builtin_bounds: builtin_bounds, projection_bounds: projection_bounds, } </del> <ins> ty::ExistentialBounds::new(region_bound, builtin_bounds, projection_bounds) </ins> } /// Given the bounds on an object, determines what single region bound

Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/


Question: x => tcx.ty_error_with_message( DUMMY_SP, <del> &format!("unexpected const parent in type_of_def_id(): {:?}", x), </del> <ins> &format!("unexpected const parent in type_of(): {:?}", x), </ins> ), } }

<!-- 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. --%5D%0D%0Apub%20trait%20IceIce%3CT%3E%0D%0Awhere%0D%0A%20%20%20%20for%3C'a%3E%20T%3A%20'a%2C%0D%0A%7B%0D%0A%20%20%20%20type%20Ice%3C'v%3E%3A%20IntoIterator%3CItem%20%3D%20%26'v%20T%3E%3B%0D%0A%7D%0D%0A%0D%0Afn%20main()%20%7B%7D%0D%0A) <!-- 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. --The ICE happens on , and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Maybe related to
Bisection: bash cargo bisect-rustc --regress ice --test-dir=foo `
Looks like
ICE happens on stable and also even without the line so no requires-nightly. label regression-from-stable-to-stable, A-traits
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low


Question: <ins> // aux-build:issue-69725.rs extern crate issue_69725; use issue_69725::Struct; fn crash<A>() { let _ = Struct::<A>::new().clone(); //~^ ERROR: no method named `clone` found } fn main() {} </ins>

I tried code very similar to this: and it produces some type of type checking error when uncommenting the line beginning with . : Backtrace:
The error is likely due to the fact that the trait bounds on don't include for , though the compiler/type checker crashing is still likely a bug.
That code was introduced in , cc Submitted as a quick fix.
I can't get it to work in the same crate, just with two crates, where the first one depends on the other: modify labels: -E-needs-mcve
Thanks I included a test in the PR.


Question: use core::mem::*; <ins> #[cfg(panic = "unwind")] </ins> use std::rc::Rc; #[test]

The test in leaks memory, which makes a Miri run of the test suite fail: Running Miri on the test suite is helpful to find bugs, so we should avoid deliberate leaks to still be able to detect accidental ones. Can the test be changed to use some other means of ensuring that is not called, e.g. with a type? Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim I made the test I should fix it
thanks. :-) Let me know if you need any help.


Question: }).collect::<Result<Vec<_>, _>>() }).collect::<Result<Vec<_>, _>>()?; <del> let (inh_first, inh_second) = { let mut inh_variants = (0..variants.len()).filter(|&v| { variants[v].iter().all(|f| f.abi != Abi::Uninhabited) }); (inh_variants.next(), inh_variants.next()) }; if inh_first.is_none() { // Uninhabited because it has no variants, or only uninhabited ones. return Ok(tcx.intern_layout(LayoutDetails::uninhabited(0))); } </del> if def.is_union() { let packed = def.repr.packed(); if packed && def.repr.align > 0 {

Uninhabited variants should ideally be irrelevant to the representation, just like in enums. As a test, this prints out 0 instead of 8: This happens because rustc considers unions more like structs than enums, and the sees a single variant with two fields, one of which is uninhabited. I have a fix for this, but it's slightly easier to bundle it with some other changes I'm working on.
This becomes a problem when making an array of unions: The above code represents a regression (prints 42 on stable, garbage on beta/nightly).
I didn't realize it was a regression to beta - in that case I'll put up an independent fix so that it can be backported if desired.
Although I can't trigger it on the playground, you code is actually triggering an ICE for me: EDIT: I bisected the ICE to somewhere between "rust 1.23.0-nightly ( 2017-11-25)" and "rust 1.23.0-nightly ( 2017-11-26)".
cc
I put up a PR to fix this, but I'm still confused about the ICE (which I moved to ).


Question: <ins> error: expected at least one digit in exponent --> $DIR/issue-104390.rs:1:27 | LL | fn f1() -> impl Sized { & 2E } |                           ^^ error: expected at least one digit in exponent --> $DIR/issue-104390.rs:2:28 | LL | fn f2() -> impl Sized { && 2E } |                            ^^ error: expected at least one digit in exponent --> $DIR/issue-104390.rs:3:29 | LL | fn f3() -> impl Sized { &'a 2E } |                             ^^ error: expected at least one digit in exponent --> $DIR/issue-104390.rs:5:34 | LL | fn f4() -> impl Sized { &'static 2E } |                                  ^^ error: expected at least one digit in exponent --> $DIR/issue-104390.rs:7:28 | LL | fn f5() -> impl Sized { *& 2E } |                            ^^ error: expected at least one digit in exponent --> $DIR/issue-104390.rs:8:29 | LL | fn f6() -> impl Sized { &'_ 2E } |                             ^^ error: borrow expressions cannot be annotated with lifetimes --> $DIR/issue-104390.rs:3:25 | LL | fn f3() -> impl Sized { &'a 2E } |                         ^--^^^ |                          | |                          annotated with lifetime here |                          help: remove the lifetime annotation error: borrow expressions cannot be annotated with lifetimes --> $DIR/issue-104390.rs:5:25 | LL | fn f4() -> impl Sized { &'static 2E } |                         ^-------^^^ |                          | |                          annotated with lifetime here |                          help: remove the lifetime annotation error: borrow expressions cannot be annotated with lifetimes --> $DIR/issue-104390.rs:8:25 | LL | fn f6() -> impl Sized { &'_ 2E } |                         ^--^^^ |                          | |                          annotated with lifetime here |                          help: remove the lifetime annotation error: aborting due to 9 previous errors </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongSample Backtrace</strong</summary<p</p</detailsThe original code () is already fixed by , however some other mutations of the original code still ICEs with the same backtrace and error. Thanks. <brCC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If the parsing error is not needed to manifest the issue, can that be fixed () in the MCVE you provided? since more error messages just obscures the underlying ICE that needs to be fixed here.
(also this could probably use a more descriptive title that reflects the ICE, and doesn't just point to another issue, but that's just my opinion)
Is that better?
claim


Question: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",

The AVR-Rust post continues to track AVR-LLVM, which is tracking upstream LLVM. That means we are running into changes from the future LLVM 4.0. I figured we could open up this issue now to track the changes required to stay compatible. This is the current list of upgrade hazards. Note that some of the text may be nonsensical as I don't truly grok all the internals of LLVM so some changes are wild stabs in the dark. It's also possible that some failed fix for earlier problems actually caused later problems: [x] DIDescriptorFlags became a real C++ enum and not a bitset () [x] An EH personality is required for every function that can unwind () [x] pass changed header and constructor name () [x] changed API () [x] Bitcode/ReaderWriter.h has been renamed / API changed () () [x] changed API () [x] changed API () [x] prefers over () [x] string type changes () [x] is not guaranteed to be null terminated () [x] changed return types () [x] Archive support changed error handling types () [x] Teach Rust about an LLVM 4.0 API change for creating debug info for global variables () [x] Check all errors in LLVMRustArchiveIterator API () [x] Upgrade emscripten (kripken/emscripten-fastcomp, kripken/emscripten-fastcomp-clang) [x] Alignment now represented with 32 bits instead of 64 () [x] API changed again () [x] now takes an instead of a and () [x] Symbol lookup error when linking dylibs () [x] Undefined behavior in tests () [x] Unoptimised builds of compilerbuiltins on ARM have references to () A WIP PR that performs the upgrade! Some issues whose resolution is believed to be blocked on LLVM 4.0: [ ]
Next time we do this upgrade we'll need emscripten to do it to. It would be good if we could pull in a working llvm wasm backend in the same upgrade, but that may not be ready before the end of the year.
For the record, I am also working with a fork of LLVM that is tracking upstream (not AVR-LLVM but similar in spirit) and am starting to work on this now.


Question: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",

I'm looking through the AVR-Rust commits and I'd love to coordinate --- feel free to ping me on IRC () or via mail!
Note that there is a regression reported against llvm 4.0 regarding the powi intrinsic on armhf targets: I'm explicitly mentioning this here, because there were previously problems with it, see and related issues. Also cc rust-lang-nursery/compiler-builtins, an issue about the same problem in the compiler-rt rust port.
To clarify what I think the is referring to (correct me if I'm wrong) In LLVM 3.9 and before, the calling convention LLVM used with the powidf2 and powisf2 intrinsics was basically the C calling convention In LLVM 4.0, the backend was corrected to expect these intrinsics to have the aapcs calling convention One person that aapcs is expected for powis2f and powid2f, while another a claiming that the normal C calling convention should be used. So it seems that if the LLVM change is not reverted (expected powisf2 to be aapcs) then we need to update our definition. This is going to be a huge PITA for supporting multiple LLVM versions as well. We need to select the calling convention depending on the LLVM version as well...
Any objections to doing that coordination here on GitHub, or on one of our forks?
I don't have strong preferences for the communication channel.
should address what is listed as API changes" above (the core of the change is in how attributes are represented).
I would prefer to upstream LLVM 4.0 compatibility patches sooner rather than later. That includes my own work obviously, but I'm also looking at the commits I cherry-picked from AVR-Rust. In particular, looks like a reasonable simplification even independent of LLVM 4.0 compatibility, and looks like a nice little self-contained fix. Could you create PRs for those? (If you don't have the time but are otherwise fine with upstreaming, I'd be happy to manage that, giving proper credit of course.)
Absolutely! I wasn't really sure how much we could expect LLVM 4 to change as it goes towards stable / how much churn the Rust maintainers would want to put up with. I'll get those pulled out and submitted soon. I think I'm also starting to understand some of the silly error handling that the new LLVM does.


Question: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",

Awesome, thanks in advance!
BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of
Does anyone have ETA? I'd like to know when I can use AVR. :)
You should follow along at avr-rust/rust for the AVR-specific issues. Upgrading to LLVM 4 will not magically yield AVR support.
Ok, thank you!
I've created for the API change.
I've also created for another debug info API change.
After putting all of those patches on top of master, was successfully built. I got several undefined references, most likely due to my local LLVM setup.
I think the next step after all those patches land is to allow LLVM 4.0 in the configure/rustbuild scripts and then actually update the submodule.
We'll also need to fix that AAPCS bug first, I just noticed it
Don't forget : I think that means that the Rust fork of LLVM is following the Emscripten fork of LLVM, thus Emscripten needs to upgrade to LLVM 4.0 / master before Rust can.
And I'm hoping to supersede it with
I just ran into which changed the alignment from u64 to u32. Will think about a proper fix later, unless someone beats me to it (but should merge first to avoid further conflicts).
And it says So, that will be "exciting".
Is there much left blocking an upgrade?
This: Has to be done too but I don't know if it's currently being worked on. Any info on that ^?
No nobody is actively working on an emscripten upgrade. Since even when that is done it will probably take a lot of work to land an LLVM upgrade, there's probably more we can do to prepare. Once we decide we want to do it, somebody can prepare a patch to throw at the bots. It seems likely stuff will not work and it will be a slog to fix it all, which will give us time. We don't need emcc to generate wasm stds, just a fairly small patch on our LLVM branch that will hopefully port without much difficulty. So if somebody feels motivated, it's not too soon to start going after it. As to the emscripten upgrade, we should at least let know that we're starting to think seriously about doing the upgrade, and need emscripten to upgrade LLVM too.


Question: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",

It seems like that could be a big effort. Another alternative is to use the LLVM wasm backend, but I still have not heard that it is generally usable yet. cc
I can look into the effort needed to update emscripten's fastcomp LLVM version, but I need to know a commit to aim for. Sounds like the goal here is 4.0, which hasn't released yet, so I guess I have to wait on that?
So far as AVR is concerned, any commit within the last month will do. There will likely be a few more months until 4.0 is actually tagged (every ~6 months a new release is made). It is quite common for projects to track LLVM master, which I'm personally a fan of.
But is it common to release snapshots from LLVM master? When LLVM itself only releases every 6 months, it seems incongruous for Rust to pick arbitrary snapshots in its 6-week release cycle.
LLVM 4.0 will branch in a week and the final release will happen in late feburary (schedule says 21st for final tag, but this is flexible IIRC).
From the llvm-dev mailing list:
branch has happened
An update on the "powidf2 / powisf2 calling convention changed" situation: The regression has been fixed on llvm master () however from what I can tell the fixes are not yet in the 4.0 branch, although the fix may be backported ().
I've started working on updating emscripten kripken/emscripten-fastcomp kripken/emscripten-fastcomp-clang I've also created a new bug requesting that the regression fix be merged into 4.0 .
says the emcc LLVM upgrade is ready to go. or are we prepared to begin the Rust LLVM upgrade? I think what needs to happen is to submit the Rust PR and start throwing it against the bots. Once it looks like that is close to landing then we'll have to coordinate both project's upgrades to minimize the breakage window where rustc and emcc have different backends. I'm not sure how best to do that - we might just try to upgrade as simultaneously as possible and accept up to a few days of breakage, or we might ask emscripten to stage their build such that they can swap their incoming branch right after we land to master.


Question: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",

needs to know the exact LLVM commit we're moving to as well, and that will become clear once the PR starts working through the queue. The stars are aligning. Let's make this happen. Thanks for doing the fastcomp upgrade.
We are not fully compatible with LLVM 4.0. I have heard from at least one person (on IRC) that building against stock LLVM 4.0 (RC) does not work. I haven't personally inspected all failures, but there's at least two things still missing: (and possibly ). It shouldn't be a conceptually difficult patch to apply the equivalent changes to rustc, but possibly a big diff. I haven't digested the implications yet, but it might be a relatively simple change localized to the function in that currently calls .
The fix has been merged into the 4.0 release (). I'm going to try and build Rust against stock LLVM 4.0 and figure out what needs modifying.
On top of what mentioned: now takes an instead of a and ()
I've got a half-baked patch to use the new signature for I'm not familiar enough with Rust internals to finish it off. I ran into a problem in as it is given a but in order to use we need a . We need to call in order to build an instance of .
I've opened for the change that mentioned. I've also opened for the 32-bit alignment change. I believe that is the only thing we need to update aside from these two PRs in order to get the compiler to successfully be built with LLVM 4.0.
So to summarize where we are with LLVM 4 (correct me if I'm wrong): 4.0 will be released in about 1 week (2/21). are no known issues with supporting LLVM 4.0, but there are probably issues that will be discovered once we try to use it in nightlies. runs on in-tree LLVM + LLVM 3.7 (so PRs haven't actually been tested on LLVM 4.0 yet). support LLVM back to ~3.6(?


Question: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",

)~ 3.7 and will continue to support it until either: a. It's so old that it can be removed without bothering package maintainers b. We need at least version X in order to fix an important bug c. The API is so different from version Y that it's a huge pain to support will open a PR to update the submodule shortly after release but it will take a month to land due to: a. Waiting for emscripten ( -) b. Bugs in upstream c. Missed LLVM API changes d. Making bors happy e. All of the above
Thanks for the summary The only correction I'd make is that in your point (4) you can s/3.6/3.7/, but otherwise it's accurate :) If you'd like to start preparing a PR to update to LLVM 4.0 I don't think we need to block waiting for LLVM itself to release 4.0. Currently only one Travis builder runs on each PR but we could temporarily allow more builders running on an LLVM 4.0 PR to start weeding out bugs before it hits
I gave it a go but I don't think my git-fu (or patience) is strong enough to handle a big merge like this. What I can do is try to run rustc with upstream LLVM and file/fix issues as I find them. There is at least one issue remaining as of (details to come).
Whoever ends up doing the LLVM upgrade, please also upgrade the compiler-rt submodule so that the sanitizer related LLVM passes don't diverge from what the sanitizer runtimes expect.
In fact, if you upgrade before the release, they usually mention your project in the release notes. :)
So whats the next issue(s) to subscribe to in the race-to-AVR? :)
As says on , we can integrate the latest Rust master into the avr-rust compiler. After that, we can spend some time getting compiling for AVR. Once that is working, we could then start looking into upstreaming the AVR target to Rust.
AVR-specific issues can be raised / tracked in For example, there are two that I'm aware of right now:
has been closed, so that can be checked off in the top post.


Question: <ins> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:16:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:5 | LL |     &<A<T> as Foo<T>>::BAR |     ^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

File: /tmp/icemaker/issue--2.rs 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
cc


Question: } fn visit_ty(&mut self, ty: Ty<'tcx>) -> std::ops::ControlFlow<Self::BreakTy> { <del> if let ty::Alias(ty::Projection, alias_ty) = *ty.kind() && self.tcx.is_impl_trait_in_trait(alias_ty.def_id) && self.tcx.impl_trait_in_trait_parent_fn(alias_ty.def_id) == self.fn_def_id && self.seen.insert(alias_ty.def_id) </del> <ins> if let ty::Alias(ty::Projection, unshifted_alias_ty) = *ty.kind() && self.tcx.is_impl_trait_in_trait(unshifted_alias_ty.def_id) && self.tcx.impl_trait_in_trait_parent_fn(unshifted_alias_ty.def_id) == self.fn_def_id && self.seen.insert(unshifted_alias_ty.def_id) </ins> { // We have entered some binders as we've walked into the // bounds of the RPITIT. Shift these binders back out when // constructing the top-level projection predicate. <del> let alias_ty = self.tcx.fold_regions(alias_ty, |re, _| { </del> <ins> let shifted_alias_ty = self.tcx.fold_regions(unshifted_alias_ty, |re, depth| { </ins> if let ty::ReLateBound(index, bv) = re.kind() { <ins> if depth != ty::INNERMOST { return self.tcx.mk_re_error_with_message( DUMMY_SP, "we shouldn't walk non-predicate binders with `impl Trait`...", ); } </ins> self.tcx.mk_re_late_bound(index.shifted_out_to_binder(self.depth), bv) } else { re

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve


Question: a: ty::Region<'tcx>, bound: VerifyBound<'tcx>, ) { <ins> if let ty::ReEmpty = a { return; } </ins> let type_test = self.verify_to_type_test(kind, a, bound); self.add_type_test(type_test); }

The following code () panics the compiler in stable 1.38.0, beta 1.39.0-beta.6, and nightly 2019-10-17: Removing the bound or filling it with makes it compile just fine. Error + backtrace:
cc
Hmm, I didn't know that adding a "syntactically trivial bound" could cause something like this. Is there some implicit bound that gets in cases like this?
minimized test case ():
The minimized test worked in previous stable Rust versions (at least in 1.33 under 2015 edition; though 2018 edition breaks there, which indicates this is with 99.999% certainty injected by MIR-borrowck...)
triage: P-high. Adding self to assignee list; removing I-nominated.


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. // aux-build:issue-11908-2.rs // no-prefer-dynamic // ignore-android this test is incompatible with the android test runner // error-pattern: multiple rlib candidates for `collections` found // see comments in issue-11908-1 for what's going on here extern crate collections; fn main() {} </ins>

Built glfw-rs using rust 0.10-pre. When referencing this crate in another source file and building, I get error: internal compiler error: unexpected failure This message reflects a bug in the Rust compiler. We would appreciate a bug report: note: the compiler hit an unexpected failure path. this is a bug Ok(task 'rustc' failed at 'assertion failed: ()', ) This is on OSX 10.9: rustc 0.10-pre ( 2014-02-18 10:16:48 -0800) host: x8664-apple-darwin
This means that you've got two versions of the same lying around, and doesn't like having two versions. This will be fixed by , I just need to land it :(
I have just build the library for the first time, and I can only find one dylib for it on my system (next to the rlib, but I gues that shouldn't cause any problems). Is there another possibility for this error? Gesendet: Mittwoch, 19. Februar 2014 um 01:09 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () This means that you've got two versions of the same libglfw- lying around, and rustc doesn't like having two versions. This will be fixed by , I just need to land it :( — Reply to this email directly or view it on GitHub.
my reading of is that having a dylib and an rlib simultaneously is a problem.
Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem.
sorry, my mistake in parsing the title of .
Yes, indeed, I had several identical dylibs, but it wasn't the glfw-rs.. there were rust libs in /usr/local/lib and /usr/local/lib/rustlib/... Thanks! Gesendet: Mittwoch, 19.


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. // aux-build:issue-11908-2.rs // no-prefer-dynamic // ignore-android this test is incompatible with the android test runner // error-pattern: multiple rlib candidates for `collections` found // see comments in issue-11908-1 for what's going on here extern crate collections; fn main() {} </ins>

Februar 2014 um 17:15 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem. — Reply to this email directly or view it on GitHub.
so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then?
Nono, the ticket can be closed for now. Thanks for your help! Gesendet: Mittwoch, 19. Februar 2014 um 21:30 UhrVon: "Felix S Klock II" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then? — Reply to this email directly or view it on GitHub.


Question: | help: change the delimiters to curly braces | <del> LL | macro_rules! abc{ؼ} |                 ^ ^ </del> <ins> LL | macro_rules! abc { /* items */ } |                  ^^^^^^^^^^^^^^^ </ins> help: add a semicolon | LL | macro_rules! abc(ؼ;

I'm seeing an internal compiler error on the following input (found by ): My compiler version is: I also observe the error on , but not on .


Question: linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+strict-align,+v6,+vfp2".to_string(), </del> <ins> features: "+strict-align,+v6,+vfp2,-d32".to_string(), </ins> abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "u{1}__gnu_mcount_nc".to_string(), .. base

The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed


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

When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code.


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

And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.


Question: <ins> #![deny(unused_must_use)] fn foo() -> (Result<(), ()>, ()) { (Ok::<(), ()>(()), ()) } fn main() { (Ok::<(), ()>(()),); //~ ERROR unused `std::result::Result` (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); //~^ ERROR unused `std::result::Result` //~^^ ERROR unused `std::result::Result` foo(); //~ ERROR unused `std::result::Result` ((Err::<(), ()>(()), ()), ()); //~ ERROR unused `std::result::Result` } </ins>

gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:


Question: // Not in interpret to make sure we do not use private implementation details <del> use std::borrow::{Borrow, Cow}; use std::collections::hash_map::Entry; use std::convert::TryInto; use std::error::Error; use std::fmt; use std::hash::Hash; use crate::interpret::eval_nullary_intrinsic; use rustc::hir::def::DefKind; use rustc::hir::def_id::DefId; </del> use rustc::mir; <del> use rustc::mir::interpret::{ConstEvalErr, ErrorHandled, ScalarMaybeUndef}; use rustc::traits::Reveal; use rustc::ty::layout::{self, HasTyCtxt, LayoutOf, VariantIdx}; use rustc::ty::{self, subst::Subst, Ty, TyCtxt}; use rustc_data_structures::fx::FxHashMap; use syntax::{ source_map::{Span, DUMMY_SP}, symbol::Symbol, }; use crate::interpret::{ self, intern_const_alloc_recursive, snapshot, AllocId, Allocation, AssertMessage, ConstValue, GlobalId, ImmTy, Immediate, InterpCx, InterpErrorInfo, InterpResult, MPlaceTy, Machine, Memory, MemoryKind, OpTy, PlaceTy, Pointer, RawConst, RefTracking, Scalar, StackPopCleanup, }; /// Number of steps until the detector even starts doing anything. /// Also, a warning is shown to the user when this number is reached. const STEPS_UNTIL_DETECTOR_ENABLED: isize = 1_000_000; /// The number of steps between loop detector snapshots. /// Should be a power of two for performance reasons. const DETECTOR_SNAPSHOT_PERIOD: isize = 256; /// The `InterpCx` is only meant to be used to do field and index projections into constants for /// `simd_shuffle` and const patterns in match arms. /// /// The function containing the `match` that is currently being analyzed may have generic bounds /// that inform us about the generic bounds of the constant. E.g., using an associated constant /// of a function's generic parameter will require knowledge about the bounds on the generic /// parameter. These bounds are passed to `mk_eval_cx` via the `ParamEnv` argument. fn mk_eval_cx<'mir, 'tcx>( tcx: TyCtxt<'tcx>, span: Span, param_env: ty::ParamEnv<'tcx>, can_access_statics: bool, ) -> CompileTimeEvalContext<'mir, 'tcx> { debug!("mk_eval_cx: {:?}", param_env); InterpCx::new( tcx.at(span), param_env, CompileTimeInterpreter::new(), MemoryExtra { can_access_statics }, ) } fn op_to_const<'tcx>( ecx: &CompileTimeEvalContext<'_, 'tcx>, op: OpTy<'tcx>, ) -> &'tcx ty::Const<'tcx> { // We do not have value optimizations for everything. // Only scalars and slices, since they are very common. // Note that further down we turn scalars of undefined bits back to `ByRef`. These can result // from scalar unions that are initialized with one of their zero sized variants. We could // instead allow `ConstValue::Scalar` to store `ScalarMaybeUndef`, but that would affect all // the usual cases of extracting e.g. a `usize`, without there being a real use case for the // `Undef` situation. let try_as_immediate = match op.layout.abi { layout::Abi::Scalar(..) => true, layout::Abi::ScalarPair(..) => match op.layout.ty.kind { ty::Ref(_, inner, _) => match inner.kind { ty::Slice(elem) => elem == ecx.tcx.types.u8, ty::Str => true, _ => false, }, _ => false, }, _ => false, }; let immediate = if try_as_immediate { Err(ecx.read_immediate(op).expect("normalization works on validated constants")) } else { // It is guaranteed that any non-slice scalar pair is actually ByRef here. // When we come back from raw const eval, we are always by-ref. The only way our op here is // by-val is if we are in const_field, i.e., if this is (a field of) something that we // "tried to make immediate" before. We wouldn't do that for non-slice scalar pairs or // structs containing such. op.try_as_mplace() }; let val = match immediate { Ok(mplace) => { let ptr = mplace.ptr.to_ptr().unwrap(); let alloc = ecx.tcx.alloc_map.lock().unwrap_memory(ptr.alloc_id); ConstValue::ByRef { alloc, offset: ptr.offset } } // see comment on `let try_as_immediate` above Err(ImmTy { imm: Immediate::Scalar(x), .. }) => match x { ScalarMaybeUndef::Scalar(s) => ConstValue::Scalar(s), ScalarMaybeUndef::Undef => { // When coming out of "normal CTFE", we'll always have an `Indirect` operand as // argument and we will not need this. The only way we can already have an // `Immediate` is when we are called from `const_field`, and that `Immediate` // comes from a constant so it can happen have `Undef`, because the indirect // memory that was read had undefined bytes. let mplace = op.assert_mem_place(); let ptr = mplace.ptr.to_ptr().unwrap(); let alloc = ecx.tcx.alloc_map.lock().unwrap_memory(ptr.alloc_id); ConstValue::ByRef { alloc, offset: ptr.offset } } }, Err(ImmTy { imm: Immediate::ScalarPair(a, b), .. }) => { let (data, start) = match a.not_undef().unwrap() { Scalar::Ptr(ptr) => { (ecx.tcx.alloc_map.lock().unwrap_memory(ptr.alloc_id), ptr.offset.bytes()) } Scalar::Raw { .. } => ( ecx.tcx.intern_const_alloc(Allocation::from_byte_aligned_bytes(b"" as &[u8])), 0, ), }; let len = b.to_machine_usize(&ecx.tcx.tcx).unwrap(); let start = start.try_into().unwrap(); let len: usize = len.try_into().unwrap(); ConstValue::Slice { data, start, end: start + len } } }; ecx.tcx.mk_const(ty::Const { val: ty::ConstKind::Value(val), ty: op.layout.ty }) } // Returns a pointer to where the result lives fn eval_body_using_ecx<'mir, 'tcx>( ecx: &mut CompileTimeEvalContext<'mir, 'tcx>, cid: GlobalId<'tcx>, body: &'mir mir::Body<'tcx>, ) -> InterpResult<'tcx, MPlaceTy<'tcx>> { debug!("eval_body_using_ecx: {:?}, {:?}", cid, ecx.param_env); let tcx = ecx.tcx.tcx; let layout = ecx.layout_of(body.return_ty().subst(tcx, cid.instance.substs))?; assert!(!layout.is_unsized()); let ret = ecx.allocate(layout, MemoryKind::Stack); let name = ty::tls::with(|tcx| tcx.def_path_str(cid.instance.def_id())); let prom = cid.promoted.map_or(String::new(), |p| format!("::promoted[{:?}]", p)); trace!("eval_body_using_ecx: pushing stack frame for global: {}{}", name, prom); // Assert all args (if any) are zero-sized types; `eval_body_using_ecx` doesn't // make sense if the body is expecting nontrivial arguments. // (The alternative would be to use `eval_fn_call` with an args slice.) for arg in body.args_iter() { let decl = body.local_decls.get(arg).expect("arg missing from local_decls"); let layout = ecx.layout_of(decl.ty.subst(tcx, cid.instance.substs))?; assert!(layout.is_zst()) } ecx.push_stack_frame( cid.instance, body.span, body, Some(ret.into()), StackPopCleanup::None { cleanup: false }, )?; // The main interpreter loop. ecx.run()?; // Intern the result intern_const_alloc_recursive(ecx, tcx.static_mutability(cid.instance.def_id()), ret)?; debug!("eval_body_using_ecx done: {:?}", *ret); Ok(ret) } #[derive(Clone, Debug)] pub enum ConstEvalError { NeedsRfc(String), ConstAccessesStatic, } impl<'tcx> Into<InterpErrorInfo<'tcx>> for ConstEvalError { fn into(self) -> InterpErrorInfo<'tcx> { err_unsup!(Unsupported(self.to_string())).into() } } impl fmt::Display for ConstEvalError { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { use self::ConstEvalError::*; match *self { NeedsRfc(ref msg) => { write!(f, ""{}" needs an rfc before being allowed inside constants", msg) } ConstAccessesStatic => write!(f, "constant accesses static"), } } } impl Error for ConstEvalError {} // Extra machine state for CTFE, and the Machine instance pub struct CompileTimeInterpreter<'mir, 'tcx> { /// When this value is negative, it indicates the number of interpreter /// steps *until* the loop detector is enabled. When it is positive, it is /// the number of steps after the detector has been enabled modulo the loop /// detector period. pub(super) steps_since_detector_enabled: isize, /// Extra state to detect loops. pub(super) loop_detector: snapshot::InfiniteLoopDetector<'mir, 'tcx>, } #[derive(Copy, Clone, Debug)] pub struct MemoryExtra { /// Whether this machine may read from statics can_access_statics: bool, } impl<'mir, 'tcx> CompileTimeInterpreter<'mir, 'tcx> { fn new() -> Self { CompileTimeInterpreter { loop_detector: Default::default(), steps_since_detector_enabled: -STEPS_UNTIL_DETECTOR_ENABLED, } } } impl<K: Hash + Eq, V> interpret::AllocMap<K, V> for FxHashMap<K, V> { #[inline(always)] fn contains_key<Q: ?Sized + Hash + Eq>(&mut self, k: &Q) -> bool where K: Borrow<Q>, { FxHashMap::contains_key(self, k) } #[inline(always)] fn insert(&mut self, k: K, v: V) -> Option<V> { FxHashMap::insert(self, k, v) } #[inline(always)] fn remove<Q: ?Sized + Hash + Eq>(&mut self, k: &Q) -> Option<V> where K: Borrow<Q>, { FxHashMap::remove(self, k) } #[inline(always)] fn filter_map_collect<T>(&self, mut f: impl FnMut(&K, &V) -> Option<T>) -> Vec<T> { self.iter().filter_map(move |(k, v)| f(k, &*v)).collect() } #[inline(always)] fn get_or<E>(&self, k: K, vacant: impl FnOnce() -> Result<V, E>) -> Result<&V, E> { match self.get(&k) { Some(v) => Ok(v), None => { vacant()?; bug!("The CTFE machine shouldn't ever need to extend the alloc_map when reading") } } } #[inline(always)] fn get_mut_or<E>(&mut self, k: K, vacant: impl FnOnce() -> Result<V, E>) -> Result<&mut V, E> { match self.entry(k) { Entry::Occupied(e) => Ok(e.into_mut()), Entry::Vacant(e) => { let v = vacant()?; Ok(e.insert(v)) } } } } crate type CompileTimeEvalContext<'mir, 'tcx> = InterpCx<'mir, 'tcx, CompileTimeInterpreter<'mir, 'tcx>>; </del> <ins> use rustc::ty::layout::VariantIdx; use rustc::ty::{self, TyCtxt}; </ins> <del> impl interpret::MayLeak for ! { #[inline(always)] fn may_leak(self) -> bool { // `self` is uninhabited self } } impl<'mir, 'tcx> interpret::Machine<'mir, 'tcx> for CompileTimeInterpreter<'mir, 'tcx> { type MemoryKinds = !; type PointerTag = (); type ExtraFnVal = !; type FrameExtra = (); type MemoryExtra = MemoryExtra; type AllocExtra = (); type MemoryMap = FxHashMap<AllocId, (MemoryKind<!>, Allocation)>; const STATIC_KIND: Option<!> = None; // no copying of statics allowed // We do not check for alignment to avoid having to carry an `Align` // in `ConstValue::ByRef`. const CHECK_ALIGN: bool = false; #[inline(always)] fn enforce_validity(_ecx: &InterpCx<'mir, 'tcx, Self>) -> bool { false // for now, we don't enforce validity } fn find_mir_or_eval_fn( ecx: &mut InterpCx<'mir, 'tcx, Self>, instance: ty::Instance<'tcx>, args: &[OpTy<'tcx>], ret: Option<(PlaceTy<'tcx>, mir::BasicBlock)>, _unwind: Option<mir::BasicBlock>, // unwinding is not supported in consts ) -> InterpResult<'tcx, Option<&'mir mir::Body<'tcx>>> { debug!("find_mir_or_eval_fn: {:?}", instance); // Only check non-glue functions if let ty::InstanceDef::Item(def_id) = instance.def { // Execution might have wandered off into other crates, so we cannot do a stability- // sensitive check here.  But we can at least rule out functions that are not const // at all. if ecx.tcx.is_const_fn_raw(def_id) { // If this function is a `const fn` then as an optimization we can query this // evaluation immediately. // // For the moment we only do this for functions which take no arguments // (or all arguments are ZSTs) so that we don't memoize too much. // // Because `#[track_caller]` adds an implicit non-ZST argument, we also cannot // perform this optimization on items tagged with it. let no_implicit_args = !instance.def.requires_caller_location(ecx.tcx()); if args.iter().all(|a| a.layout.is_zst()) && no_implicit_args { let gid = GlobalId { instance, promoted: None }; ecx.eval_const_fn_call(gid, ret)?; return Ok(None); } } else { // Some functions we support even if they are non-const -- but avoid testing // that for const fn!  We certainly do *not* want to actually call the fn // though, so be sure we return here. return if ecx.hook_panic_fn(instance, args, ret)? { Ok(None) } else { throw_unsup_format!("calling non-const function `{}`", instance) }; } } // This is a const fn. Call it. Ok(Some(match ecx.load_mir(instance.def, None) { Ok(body) => *body, Err(err) => { if let err_unsup!(NoMirFor(ref path)) = err.kind { return Err(ConstEvalError::NeedsRfc(format!( "calling extern function `{}`", path )) .into()); } return Err(err); } })) } fn call_extra_fn( _ecx: &mut InterpCx<'mir, 'tcx, Self>, fn_val: !, _args: &[OpTy<'tcx>], _ret: Option<(PlaceTy<'tcx>, mir::BasicBlock)>, _unwind: Option<mir::BasicBlock>, ) -> InterpResult<'tcx> { match fn_val {} } fn call_intrinsic( ecx: &mut InterpCx<'mir, 'tcx, Self>, span: Span, instance: ty::Instance<'tcx>, args: &[OpTy<'tcx>], ret: Option<(PlaceTy<'tcx>, mir::BasicBlock)>, _unwind: Option<mir::BasicBlock>, ) -> InterpResult<'tcx> { if ecx.emulate_intrinsic(span, instance, args, ret)? { return Ok(()); } // An intrinsic that we do not support let intrinsic_name = ecx.tcx.item_name(instance.def_id()); Err(ConstEvalError::NeedsRfc(format!("calling intrinsic `{}`", intrinsic_name)).into()) } </del> <ins> use syntax::{source_map::DUMMY_SP, symbol::Symbol}; </ins> <del> fn assert_panic( ecx: &mut InterpCx<'mir, 'tcx, Self>, _span: Span, msg: &AssertMessage<'tcx>, _unwind: Option<mir::BasicBlock>, ) -> InterpResult<'tcx> { use rustc::mir::interpret::PanicInfo::*; Err(match msg { BoundsCheck { ref len, ref index } => { let len = ecx .read_immediate(ecx.eval_operand(len, None)?) .expect("can't eval len") .to_scalar()? .to_machine_usize(&*ecx)?; let index = ecx .read_immediate(ecx.eval_operand(index, None)?) .expect("can't eval index") .to_scalar()? .to_machine_usize(&*ecx)?; err_panic!(BoundsCheck { len, index }) } Overflow(op) => err_panic!(Overflow(*op)), OverflowNeg => err_panic!(OverflowNeg), DivisionByZero => err_panic!(DivisionByZero), RemainderByZero => err_panic!(RemainderByZero), ResumedAfterReturn(generator_kind) => err_panic!(ResumedAfterReturn(*generator_kind)), ResumedAfterPanic(generator_kind) => err_panic!(ResumedAfterPanic(*generator_kind)), Panic { .. } => bug!("`Panic` variant cannot occur in MIR"), } .into()) } </del> <ins> use crate::interpret::{intern_const_alloc_recursive, ConstValue, InterpCx}; </ins> <del> fn ptr_to_int(_mem: &Memory<'mir, 'tcx, Self>, _ptr: Pointer) -> InterpResult<'tcx, u64> { Err(ConstEvalError::NeedsRfc("pointer-to-integer cast".to_string()).into()) } </del> <ins> mod error; mod eval_queries; </ins> <del> fn binary_ptr_op( _ecx: &InterpCx<'mir, 'tcx, Self>, _bin_op: mir::BinOp, _left: ImmTy<'tcx>, _right: ImmTy<'tcx>, ) -> InterpResult<'tcx, (Scalar, bool, Ty<'tcx>)> { Err(ConstEvalError::NeedsRfc("pointer arithmetic or comparison".to_string()).into()) } fn find_foreign_static( _tcx: TyCtxt<'tcx>, _def_id: DefId, ) -> InterpResult<'tcx, Cow<'tcx, Allocation<Self::PointerTag>>> { throw_unsup!(ReadForeignStatic) } #[inline(always)] fn init_allocation_extra<'b>( _memory_extra: &MemoryExtra, _id: AllocId, alloc: Cow<'b, Allocation>, _kind: Option<MemoryKind<!>>, ) -> (Cow<'b, Allocation<Self::PointerTag>>, Self::PointerTag) { // We do not use a tag so we can just cheaply forward the allocation (alloc, ()) } #[inline(always)] fn tag_static_base_pointer(_memory_extra: &MemoryExtra, _id: AllocId) -> Self::PointerTag { () } fn box_alloc( _ecx: &mut InterpCx<'mir, 'tcx, Self>, _dest: PlaceTy<'tcx>, ) -> InterpResult<'tcx> { Err(ConstEvalError::NeedsRfc("heap allocations via `box` keyword".to_string()).into()) } fn before_terminator(ecx: &mut InterpCx<'mir, 'tcx, Self>) -> InterpResult<'tcx> { { let steps = &mut ecx.machine.steps_since_detector_enabled; *steps += 1; if *steps < 0 { return Ok(()); } *steps %= DETECTOR_SNAPSHOT_PERIOD; if *steps != 0 { return Ok(()); } } let span = ecx.frame().span; ecx.machine.loop_detector.observe_and_analyze(*ecx.tcx, span, &ecx.memory, &ecx.stack[..]) } #[inline(always)] fn stack_push(_ecx: &mut InterpCx<'mir, 'tcx, Self>) -> InterpResult<'tcx> { Ok(()) } fn before_access_static( memory_extra: &MemoryExtra, _allocation: &Allocation, ) -> InterpResult<'tcx> { if memory_extra.can_access_statics { Ok(()) } else { Err(ConstEvalError::ConstAccessesStatic.into()) } } } </del> <ins> pub use error::*; pub use eval_queries::*; </ins> /// Extracts a field of a (variant of a) const. // this function uses `unwrap` copiously, because an already validated constant must have valid // fields and can thus never fail outside of compiler bugs <del> pub fn const_field<'tcx>( </del> <ins> pub(crate) fn const_field<'tcx>( </ins> tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, variant: Option<VariantIdx>,

Follow-up to agreed to move to . Generally I propose that should not contain code that is only needed by CTFE. We have and in there are they need some very deep access to Miri engine internals, but at least those are separate modules. Also, has grown pretty messy, and it does not seem like the order of definitions in that file follows any principle. We could split the file into two similar to what I did with Miri: for implementing the machine trait and defining everything that is needed during CTFE execution, and for defining the setup functions and all the glue that connects CTFE with the rest of the compiler.


Question: return None; } <del> pub fn return_type_impl_trait(self, scope_def_id: LocalDefId) -> Option<(Ty<'tcx>, Span)> { // `type_of()` will fail on these (#55796, #86483), so only allow `fn`s or closures. match self.hir().get_by_def_id(scope_def_id) { Node::Item(&hir::Item { kind: ItemKind::Fn(..), .. }) => {} Node::TraitItem(&hir::TraitItem { kind: TraitItemKind::Fn(..), .. }) => {} Node::ImplItem(&hir::ImplItem { kind: ImplItemKind::Fn(..), .. }) => {} Node::Expr(&hir::Expr { kind: ExprKind::Closure { .. }, .. }) => {} _ => return None, } let ret_ty = self.type_of(scope_def_id).instantiate_identity(); match ret_ty.kind() { ty::FnDef(_, _) => { let sig = ret_ty.fn_sig(self); let output = self.erase_late_bound_regions(sig.output()); output.is_impl_trait().then(|| { let hir_id = self.hir().local_def_id_to_hir_id(scope_def_id); let fn_decl = self.hir().fn_decl_by_hir_id(hir_id).unwrap(); (output, fn_decl.output.span()) }) } _ => None, } } </del> /// Checks if the bound region is in Impl Item. pub fn is_bound_region_in_impl_item(self, suitable_region_binding_scope: LocalDefId) -> bool { let container_id = self.parent(suitable_region_binding_scope.to_def_id());

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: self.parent_cfg = new_cfg.clone(); item.cfg = new_cfg; <ins> let old_parent = if let Some(def_id) = item.item_id.as_def_id().and_then(|def_id| def_id.as_local()) { self.parent.replace(def_id) } else { self.parent.take() }; </ins> let result = self.fold_item_recur(item); self.parent_cfg = old_parent_cfg; <ins> self.parent = old_parent; </ins> Some(result) }

From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.


Question: self.parent_cfg = new_cfg.clone(); item.cfg = new_cfg; <ins> let old_parent = if let Some(def_id) = item.item_id.as_def_id().and_then(|def_id| def_id.as_local()) { self.parent.replace(def_id) } else { self.parent.take() }; </ins> let result = self.fold_item_recur(item); self.parent_cfg = old_parent_cfg; <ins> self.parent = old_parent; </ins> Some(result) }

Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.


Question: } PatKind::Binding { name, mutability, mode, var, ty, ref subpattern, is_primary: _ } => { <del> candidate.bindings.push(Binding { name, mutability, span: match_pair.pattern.span, source: match_pair.place.clone().into_place(self.tcx, self.typeck_results), var_id: var, var_ty: ty, binding_mode: mode, }); </del> <ins> if let Ok(place_resolved) = match_pair.place.clone().try_upvars_resolved(self.tcx, self.typeck_results) { candidate.bindings.push(Binding { name, mutability, span: match_pair.pattern.span, source: place_resolved.into_place(self.tcx, self.typeck_results), var_id: var, var_ty: ty, binding_mode: mode, }); } </ins> if let Some(subpattern) = subpattern.as_ref() { // this is the `x @ P` case; have to keep matching against `P` now

Encountered an ICE when building  0.18.0 on edition 2021. I have roughly narrowed it down to the following (can probably be reduced further). Seems to be an issue with closure captures. <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The code can be further simplified to: The issue seems to be around using type annotation. If a type annotation is included, the right hand side of the let statement should always be read.
Is there a runtime check/ is MIR generated for checking if is valid? Because if that's the case then we need props2 to be caputred.
claim I should have a fix later tonight
We found another instance of this ICE that still fails with included: Found trying to migrate . Let me know if you need any more information.


Question: }; add_to_sysroot(builder, &libdir, &hostdir, &libstd_stamp(builder, compiler, target)); <ins> // Special case for stage0, to make `rustup toolchain link` and `x dist --stage 0` // work for stage0-sysroot. We only do this if the stage0 compiler comes from beta, // and is not set to a custom path. if compiler.stage == 0 && builder .build .config .initial_rustc .starts_with(builder.out.join(&compiler.host.triple).join("stage0/bin")) { // Copy bin files from stage0/bin to stage0-sysroot/bin let sysroot = builder.out.join(&compiler.host.triple).join("stage0-sysroot"); let host = compiler.host.triple; let stage0_bin_dir = builder.out.join(&host).join("stage0/bin"); let sysroot_bin_dir = sysroot.join("bin"); t!(fs::create_dir_all(&sysroot_bin_dir)); builder.cp_r(&stage0_bin_dir, &sysroot_bin_dir); // Copy all *.so files from stage0/lib to stage0-sysroot/lib let stage0_lib_dir = builder.out.join(&host).join("stage0/lib"); if let Ok(files) = fs::read_dir(&stage0_lib_dir) { for file in files { let file = t!(file); let path = file.path(); if path.is_file() && is_dylib(&file.file_name().into_string().unwrap()) { builder.copy(&path, &sysroot.join("lib").join(path.file_name().unwrap())); } } } // Copy codegen-backends from stage0 let sysroot_codegen_backends = builder.sysroot_codegen_backends(compiler); t!(fs::create_dir_all(&sysroot_codegen_backends)); let stage0_codegen_backends = builder .out .join(&host) .join("stage0/lib/rustlib") .join(&host) .join("codegen-backends"); builder.cp_r(&stage0_codegen_backends, &sysroot_codegen_backends); } </ins> } }

Currently, the beta binaries are only present in ; has only the standard library, not any binaries. That causes two issues: doesn't work with stage0-sysroot, meaning there's no way to change the standard library and use those changes at runtime without doing a full stage 1 build doesn't work. This is very rare to want to do, but can be useful when modifying the process itself, to avoid long compile times. Copying the binaries into stage0-sysroot is an easy way to fix both problems at once. Mentoring instructions: Add a call in which copies the whole directory from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We should also consider renaming to something else; the name is very confusing.
claim
The name is correct though. It is a directory you can pass in as argument to rustc.
so is . I'm not saying the name is wrong, just that it's ambiguous and not intuitive. Honestly I would rather rename all the directories to and change to or something.
is confusing too as already has a libstd. Just one from the bootstrap compiler rather than compiled from the current source.
Ok, then maybe :shrug: nearly anything would be less confusing than just appending IMO
Maybe rename stage0 to bootstrap and stage0-sysroot to stage0, matching stage1-...?
is confusing with the artifacts for , but maybe would work, keeping stage0-sysroot as is and renaming stage1 to stage1-sysroot
Reverted in
I actually wanted to recommend something like this as an alternative std benchmarking workflow. Currently I have to suggest a stage1 build.
I meant is very rare. I agree wanting to use a stage 0 toolchain with just the libstd changes is common :)
do you know when you'll have a chance to follow up here? If you're not planning to follow up, can you please release your assignment on the issue?
Sorry, I didn't follow this item recently. Ok, release it now.
claim I would like to take this issue up [with a bit of mentoring :)] if that's alright. It's my first time contributing!


Question: }; add_to_sysroot(builder, &libdir, &hostdir, &libstd_stamp(builder, compiler, target)); <ins> // Special case for stage0, to make `rustup toolchain link` and `x dist --stage 0` // work for stage0-sysroot. We only do this if the stage0 compiler comes from beta, // and is not set to a custom path. if compiler.stage == 0 && builder .build .config .initial_rustc .starts_with(builder.out.join(&compiler.host.triple).join("stage0/bin")) { // Copy bin files from stage0/bin to stage0-sysroot/bin let sysroot = builder.out.join(&compiler.host.triple).join("stage0-sysroot"); let host = compiler.host.triple; let stage0_bin_dir = builder.out.join(&host).join("stage0/bin"); let sysroot_bin_dir = sysroot.join("bin"); t!(fs::create_dir_all(&sysroot_bin_dir)); builder.cp_r(&stage0_bin_dir, &sysroot_bin_dir); // Copy all *.so files from stage0/lib to stage0-sysroot/lib let stage0_lib_dir = builder.out.join(&host).join("stage0/lib"); if let Ok(files) = fs::read_dir(&stage0_lib_dir) { for file in files { let file = t!(file); let path = file.path(); if path.is_file() && is_dylib(&file.file_name().into_string().unwrap()) { builder.copy(&path, &sysroot.join("lib").join(path.file_name().unwrap())); } } } // Copy codegen-backends from stage0 let sysroot_codegen_backends = builder.sysroot_codegen_backends(compiler); t!(fs::create_dir_all(&sysroot_codegen_backends)); let stage0_codegen_backends = builder .out .join(&host) .join("stage0/lib/rustlib") .join(&host) .join("codegen-backends"); builder.cp_r(&stage0_codegen_backends, &sysroot_codegen_backends); } </ins> } }

thanks for looking at it :) the first step is to cherry-pick the changes in to the latest master commit. Then you'll need to fix the bug Mark mentioned in , which I believe has some more details in https://rust- I think it's enough to copy the user-provided over to . Feel free to ask questions here or in https://rust-
It was mentioned that reverted this so I am reopening this unless someone can point me to the, er, revert of the revert?
Useful Links and Points for anyone who wants to work on this: Initial PR : Revert of the Initial PR : Attempt 2 : Revert of attempt 2 : If I am to understand correctly, the revert of the revert was rejected mainly because rust perf () broke. For anyone working on this issue again, here's a point to note: Just copying the entire parent to will not work as pointed out by in zulip as, suppose the rustc is installed in and you try and copy the underlying parent dir which would be . That time, will get all the binaries in . This will however work when the installation is in something like :
My suggestion would be to re-land almost as-is, except with this feature disabled when a custom is set.
claim I'll give this another shot then


Question: let source_map = self.tcx.sess.source_map(); let all_source_files = source_map.files(); <del> let (working_dir, working_dir_was_remapped) = self.tcx.sess.working_dir.clone(); </del> <ins> let (working_dir, _cwd_remapped) = self.tcx.sess.working_dir.clone(); </ins> let adapted = all_source_files.iter() .filter(|source_file| {

STR (on Linux): file that has generics usage () code DWARF info Notice that contains such entries as , possibly produced by the fact that "" is a relative path and DWATcompdir is set to "/home/yury". It is expected for core files to have absolute path e.g. ""
cc I wonder what interaction (path rewriting?) causes this result.
FWIW, produces that shows that !DIFile entries has the directory field empty (and the filename is relative)
It is a regression, since +stable has absolute locations, e.g.
could this have to do with
Likely so! I'll try to look into this in the near future
Ok so the change here can be exhibited with this script: If you execute that script you see: but if you remove you see: It appears that if upstream crates (like libstd) use then their filename is listed as the original relative source file instead of the absolute path name that it had previous to when it wasn't compiled with . So somehow using to compile libstd is affecting downstream crates to have relative path names instead of old absolute path names. It makes sense to me that the absolute path name goes away with (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping. would you be able to help point me in the direction of where this change in logic might happen? If so I can test out a patch!
This should be what you're looking for: One solution would be to compile libstd with absolute paths and apply proper remapping to those.
Ah that's perfect! I'll see if I can work up a solution to that soon