Question: candidates.vec.push(FnPointerCandidate); } } <ins> // Provide an impl for suitable functions, rejecting `#[target_feature]` functions (RFC 2396). ty::FnDef(def_id, _) => { if let ty::FnSig { unsafety: hir::Unsafety::Normal, abi: Abi::Rust, c_variadic: false, .. } = self_ty.fn_sig(self.tcx()).skip_binder() { if self.tcx().codegen_fn_attrs(def_id).target_features.is_empty() { candidates.vec.push(FnPointerCandidate); } } } </ins> _ => {} }

The "unsafety checker enhancement" should only affect unsafe functions that are made unsafe through , but not other means (explicit or block).
I'm new to the compiler, but it seemed non-trivial to change functions to unsafe when lowering to HIR. It looks to me like you'd end up with just as many exceptions (ignoring the unsafe in some scenarios), in addition tracking the origin of the . On the other hand it was pretty trivial to not implement the Fn traits instead. I'll open a PR with my fix, but please close it if the other method is preferred.
So there are sort of two questions here. One of them is what user-visible behavior is permitted, and the other is how precisely that is implemented in the compiler. I think the latter only concerns the team in-so-far as it represents the impact on the language spec and on the "mental model" that users must keep in mind. Nominating for the lang-team meeting to discuss solution, which is simply to make "target-feature" functions not implement the traits (just as functions do not implement the traits, along with functions with non-Rust ABIs etc).
I think I was tagged by mistake :wink:
Apologies! Fixed. Github autocompleted that for me. Here I was feeling so grateful to it.
We discussed this in . The conclusion was that the fix that proposed is good for right now. It's already the case that many items do not implement the function trait (e.g., those with custom ABIs or which are unsafe), so this would be "yet another" case (admittedly a somewhat different one in that this case doesn't show up in the type of function pointers, for better or worse). We uncovered a few other interesting observations: pointed out that their ideal preference would be to have something like " only implements " within an unsafe block, but of course the trait system has no precedent for that. It would be sort of like a attached to the impl block (i.e., the impl is usable in some context where unsafe code is allowed). Another possibility might be " only implements within a fn that has a suitable target feature in scope". This is an interesting idea because, although the pointer could escape in the form of a , the idea is that once you enter , you've already demonstrated that you possess the target feature, so it's ok if the value escapes.


Question: candidates.vec.push(FnPointerCandidate); } } <ins> // Provide an impl for suitable functions, rejecting `#[target_feature]` functions (RFC 2396). ty::FnDef(def_id, _) => { if let ty::FnSig { unsafety: hir::Unsafety::Normal, abi: Abi::Rust, c_variadic: false, .. } = self_ty.fn_sig(self.tcx()).skip_binder() { if self.tcx().codegen_fn_attrs(def_id).target_features.is_empty() { candidates.vec.push(FnPointerCandidate); } } } </ins> _ => {} }

(This would be like a clause.) To that end, I was thinking that you could model this last point using closures, but I found that it doesn't work. In particular, gives an error, even if it appears inside of a function annotated with . This seems like something we should discuss, but it's a separate issue. We did discuss briefly whether target features should be part of the type of function pointers but I think the conclusion was 'well maybe but there is already stable code out there that lets you coerce, and it seems rather niche'. We also discussed whether we should permit one to annotate closures with target-feature annotations. In any case, those are things we can address separately from this issue, but the point is that adopting more accepting solutions can be done in the future.
I'm going to move the question of whether closures should "inherit" target features to the main tracking issue -- I'm not sure if that is something that was discussed as part of the original RFC discussion?
Opened to discuss closures.


Question: // highlighted text will always be `&<expr>` and // thus can transform to `&mut` by slicing off // first ASCII character and prepending "&mut ". <del> let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); </del> <ins> if src.starts_with('&') { let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); } </ins> } }

When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

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


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

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


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

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


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

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


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

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


Question: <ins> error[E0308]: mismatched types --> $DIR/default-body-type-err-2.rs:8:9 | LL |         42 |         ^^- help: try using a conversion method: `.to_string()` |         | |         expected struct `String`, found integer error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Here's a MVCE: I expected to see this happen: compilation fails because I'm clearly returning an instead of a Instead, this happened: bad codegen ("async fn resumed after completion") :
This is specifically a bug with default body in traits, this doesn't happen in s. I'll check it out, it's probably a very simple fix.


Question: <ins> // check-pass // This is a valid macro. Commit 4 in #95159 broke things such that it failed // with a "missing tokens in macro arguments" error, as reported in #95267. macro_rules! f { ( /// ab ) => {}; } fn main() { f!(); } </ins>

Cross post from Works fine on stable Rust.
That post is written by me. I've opened a PR , and made some comments there. I'm not an expert on Rust, actually I'm an amateur programmer, and this is what I can do for now.
61.0-nightly ( 2022-03-22) works so this is a very recent nightly regression.
I see that too when compiling
same issue on ubuntu20
Maybe related to this issue. Here is a snippet of macro with on the match side: Pass with rustc 1.61.0-nightly ( 2022-03-22), you can try this snippet via Failed with rustc 1.61.0-nightly ( 2022-03-23), you can try this snippet via , the code can be expanded on playground with: Expand macros in code using the nightly compiler. 61.0-nightly (2022-03-19 )
The piece of code looks surprising, but bisection lead to
Ok, I found it :smile:
Thanks for the report. Should be an easy fix, I will get to it on Monday.
I think is right to some extent. Even in previous Rust version, stuff in the matcher is not so useful and will be ignored like normal comments : With rustc 1.61.0-nightly ( 2022-03-22) or other versions before, the result is: With rustc 1.61.0-nightly ( 2022-03-23), the result is:
Note that the playground's nightly is a few days old and cannot be upgraded because of how this issue affects ring ;-)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
That's an interesting observation! But I'm not a language expert and I never intended to change behaviour in , so I will fix this problem by going back to the old behaviour.


Question: make_test!(split_space_str, s, s.split(" ").count()); make_test!(split_ad_str, s, s.split("ad").count()); <ins> make_test!(to_lowercase, s, s.to_lowercase()); </ins>

I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.


Question: make_test!(split_space_str, s, s.split(" ").count()); make_test!(split_ad_str, s, s.split("ad").count()); <ins> make_test!(to_lowercase, s, s.to_lowercase()); </ins>

The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.


Question: should_continue = suggest(err, false, span, message, sugg); } } <del> LifetimeRibKind::Item => break, </del> <ins> LifetimeRibKind::Item | LifetimeRibKind::ConstParamTy => break, </ins> _ => {} } if !should_continue {

<!-- 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
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


Question: // Render unstable items. But don't render "rustc_private" crates (internal compiler crates). // Those crates are permanently unstable so it makes no sense to render "unstable" everywhere. <del> if let Some((StabilityLevel::Unstable { reason, issue, .. }, feature)) = item </del> <ins> if let Some((StabilityLevel::Unstable { reason: _, issue, .. }, feature)) = item </ins> .stability(cx.tcx()) .as_ref() .filter(|stab| stab.feature != sym::rustc_private)

Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.


Question: // Render unstable items. But don't render "rustc_private" crates (internal compiler crates). // Those crates are permanently unstable so it makes no sense to render "unstable" everywhere. <del> if let Some((StabilityLevel::Unstable { reason, issue, .. }, feature)) = item </del> <ins> if let Some((StabilityLevel::Unstable { reason: _, issue, .. }, feature)) = item </ins> .stability(cx.tcx()) .as_ref() .filter(|stab| stab.feature != sym::rustc_private)

Making them less visually prominent, such as by reducing their contrast and making the warning just plain unstyled text, perhaps in the same place that stability information goes (though see for discussion on that), would help out a lot.
I would prefer this option. One benefit of showing the unstable APIs is that it invites people to test them, so having an opt-in for the curious would be good.
I would prefer an opt-out to an opt-in, that is, keep what we do today, but provide the ability to hide it if desired.
After spending some more time browsing the docs with an eye out for things that are visually distracting or attention grabbing, another option would be to just use a less attention grabbing way to denote unstable and deprecated items. Right now, they each use an extra, brightly colored box that makes them take up more visual space on the screen than stable items. On module index pages, they are actually made less prominent; they are sorted to the bottom, and made lower contrast with the background. This helps make them less attention catching, rather than more attention catching. But when browsing the methods provided on a struct or trait, they come with the big bright warning boxes that make them stand out more. I think I would still have a slight preference for having them hidden by default and just making the nightly docs easier to discover, such as having a version chooser in the header or sidebar, because of the issue mentioned in about docs of unstable items potentially being out of date. But making them less visually prominent rather than more visually prominent would help a lot.
I agree that the better way to solve this is by (perhaps) reducing the prominence of the "nightly-only" box. I don't think we should hide unstable items in the stable rustdoc generated at If someone is reading code that uses an unstable method, there's a good chance they will go to look it up in the stable docs. It would be a frustrating and confusing experience to not be able to find the method in the docs. It's a much better experience to find the method and be informed it's nightly-only / unstable. We probably don't want to reduce the prominence too much, though. If someone's looking for a method to call, it's pretty important that they notice when it's nightly-only. If they're working on a stable crate, that may mean they're not able to use the method at all.
Candidate PR at


Question: use tokenstream; use std::{cmp, fmt}; <ins> use std::mem; </ins> use rustc_data_structures::sync::{Lrc, Lock}; #[derive(Clone, RustcEncodable, RustcDecodable, PartialEq, Eq, Hash, Debug, Copy)]

This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.


Question: use tokenstream; use std::{cmp, fmt}; <ins> use std::mem; </ins> use rustc_data_structures::sync::{Lrc, Lock}; #[derive(Clone, RustcEncodable, RustcDecodable, PartialEq, Eq, Hash, Debug, Copy)]

That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.


Question: } let (mut min, mut max) = (i128::max_value(), i128::min_value()); <ins> let discr_type = def.repr.discr_type(); let bits = Integer::from_attr(tcx, discr_type).size().bits(); </ins> for (i, discr) in def.discriminants(tcx).enumerate() { if variants[i].iter().any(|f| f.abi == Abi::Uninhabited) { continue; } <del> let x = discr.val as i128; </del> <ins> let mut x = discr.val as i128; if discr_type.is_signed() { // sign extend the raw representation to be an i128 x = (x << (128 - bits)) >> (128 - bits); } </ins> if x < min { min = x; } if x > max { max = x; } }

I was trying to build which pulls in pango 0.1.3 as dependency . While building pango, rustc segfaults  meta: Crash happens in So apparently const eval produces a discriminant that doesn't match any variant's discriminant. more concretely, it happens during a match on which is the only discriminant with as its value.
weird, I am still getting the panic with todays nightly :(
Same backtrace? We do have a regression test for this exact issue
Yeah, backtrace is identical except for the rustc version string in the ICE notes. :/
Fix confirmed, thanks!


Question: /// ``` #[stable(feature = "rust1", since = "1.0.0")] pub trait ExactSizeIterator: Iterator { <del> /// Returns the exact number of times the iterator will iterate. </del> <ins> /// Returns the exact length of the iterator. </ins> /// <ins> /// The implementation ensures that the iterator will return exactly `len()` /// more times a `Some(T)` value, before returning `None`. </ins> /// This method has a default implementation, so you usually should not /// implement it directly. However, if you can provide a more efficient /// implementation, you can do so. See the [trait-level] docs for an

If the wrapped iterator implements then blindly delegates to it. The underlying iterator may know its exact size but return spurious results anyway, on which will stop iterating even though the source knows that there are elements left to iterate, meaning will indicate that there are elements left but never return them. The behavior was introduced in but didn't see any discussion.
Implementations of have soundness implications, thus marking as . That being said, the documentation for is fairly exact in its wording that the first means "end of iteration".
Hm, seeing as is not an unsafe trait, I would not expect code to be able to rely on it for soundness? Maybe we do so internally for std types though...
Unsafe code can't rely on correctness (there's for that). The length of an iterator is defined as the number of items yielded before it returns None, so Fuse's implementation is correct.
Oh my bad, I was confusing it with TrustedLen.
Ok, makes sense. But I will be pedantic here since I prefer documentation to have slightly more formal flavor. docs: The module documentation: Now resume can be interpreted as continuing the the previous iteration instead of starting a new iteration (conceptually a new iteration would require a new iterator then). Under this interpretation should report the complete length of all iteration including possible resumptions which must be known when claiming exact sizing knowledge. The documentation could use a more precise definition of what an iteration is and that resumption is really considered a new iteration.


Question: use rustc_infer::infer::{self, InferOk}; use rustc_middle::ty::subst::Subst; use rustc_middle::ty::subst::{InternalSubsts, SubstsRef}; <del> use rustc_middle::ty::GenericParamDefKind; </del> use rustc_middle::ty::{self, ToPredicate, Ty, TypeVisitable}; <ins> use rustc_middle::ty::{DefIdTree, GenericParamDefKind}; </ins> use rustc_span::symbol::Ident; use rustc_span::Span; use rustc_trait_selection::traits;

Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.


Question: ) .span_suggestion( span_with_quotes, <del> "if you meant to write a `str` literal, use double quotes", </del> <ins> msg, </ins> format!(""{}"", lit), Applicability::MachineApplicable, ).emit()

When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!


Question: <del> //@ known-bug: #123710 #[repr(packed)] #[repr(u32)] enum E { A, B, C, } fn main() { union InvalidTag { int: u32, e: E, } let _invalid_tag = InvalidTag { int: 4 }; } </del>

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details- Above original code is mutated from I guess at the top causes ICE <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE occurred at
label regression-from-stable-to-beta
searched nightlies: from nightly-2024-02-01 to nightly-2024-04-10 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailscc
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: <ins> error: expected one of `.`, `;`, `?`, `else`, or an operator, found `}` --> $DIR/issue-60075.rs:6:10 | LL |         }); |          ^ expected one of `.`, `;`, `?`, `else`, or an operator here error: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `;` --> $DIR/issue-60075.rs:6:11 | LL |     fn qux() -> Option<usize> { |                               - unclosed delimiter LL |         let _ = if true { LL |         }); |           ^ |           | |           help: `}` may belong here error: expected identifier, found `;` --> $DIR/issue-60075.rs:6:11 | LL |         }); |           ^ expected identifier error: missing `fn`, `type`, or `const` for trait-item declaration --> $DIR/issue-60075.rs:6:12 | LL |           }); |  ____________^ LL | | LL | | LL | | LL | | LL | |         Some(4) | |________^ missing `fn`, `type`, or `const` error: aborting due to 4 previous errors </ins>

I got an internal compiler error while compiling some code with a syntax error. The error is in the final line of the match statement in the function parse. () Errors:
triage: P-high. (Unnominating since there doesn't seem to be much else to discuss)
Assigning myself to look into and fix.
:
this ICE only happens for already broken code, I don't believe this is P-high.


Question: _ => (), } } <del> FnKind::ItemFn(name, ..) => { </del> <ins> FnKind::ItemFn(name, _, _, _, abi, _, attrs) => { // Skip foreign-ABI #[no_mangle] functions (Issue #31924) if abi != Abi::Rust && attr::find_by_name(attrs, "no_mangle").is_some() { return; } </ins> self.check_snake_case(cx, "function", &name.as_str(), Some(span)) } FnKind::Closure(_) => (),

Since the function is tagged the exact name presumably has to exactly match something that another system is expecting, which may not be snake case. For example, JNI bindings will look something like
Modifying lints requires an RFC now, as it can impact a LOT of code.
(By modifying I mean "major changes" not bugfixes)
Hm, while I think new lints definitely want an RFC, modifications to existing ones can probably go through the lang team's nomination process, leading to either an immediate decision or request for RFC.
I'm fine with that, just following (what I thought was) procedure. :smile:


Question: - [What is rustdoc?](what-is-rustdoc.md) - [Command-line arguments](command-line-arguments.md) - [How to read rustdoc output](how-to-read-rustdoc.md) <ins> - [In-doc settings](read-documentation/in-doc-settings.md) </ins> - [How to write documentation](how-to-write-documentation.md) - [What to include (and exclude)](write-documentation/what-to-include.md) - [The `#[doc]` attribute](write-documentation/the-doc-attribute.md)

Rustdoc has accumulated a handful of settings that users can toggle as they read docs, but we don't document them anywhere. It would be ideal if we had some documentation about these options in the Rustdoc Book that described their functionality better than the short descriptions shown on the settings page itself. !
I don't mind picking this up, unless you want to do this yourself! I do however have some questions!: The Rustdoc book you mean is right? Do you suggest adding a new section to this book or would you include it in an already existing section? What do you believe is not clear / elaborated enough in the short descriptions? I do not know the specific details of each switch are there any side-effects that are not in the short description?
Triage: no changes. The rustdoc book is that one, ! I am not a rustdoc maintainer these days (cc ) but I would probably make a new section. While the short description is good, I think it would make sense to show the options in slightly more detail, for example, maybe a before/after.
Bit of a late reply :) Do you have something to add to this? Otherwise I will follow what Steve said!


Question: // Each call to `fill_buf` sets `filled` to indicate how many bytes at the start of `buf` are // initialized with bytes from a read. filled: usize, <ins> // This is the max number of bytes returned across all `fill_buf` calls. We track this so that we // can accurately tell `read_buf` how many bytes of buf are initialized, to bypass as much of its // defensive initialization as possible. Note that while this often the same as `filled`, it // doesn't need to be. Calls to `fill_buf` are not required to actually fill the buffer, and // omitting this is a huge perf regression for `Read` impls that do not. initialized: usize, </ins> } impl Buffer { #[inline] pub fn with_capacity(capacity: usize) -> Self { let buf = Box::new_uninit_slice(capacity); <del> Self { buf, pos: 0, filled: 0 } </del> <ins> Self { buf, pos: 0, filled: 0, initialized: 0 } </ins> } #[inline]

I tried this code: I expected to see this happen: Instead, this happened: The problem doesn't occur with optimization enabled. It most recently worked on: Also fails on: modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for reporting this! This is an issue with a debug build so it's unlikely to be prioritized high but I'm interested in helping out because this is very goofy. The slow code here is the Iterator impl on slices. I think in the last stable release we switched the implementation of BufReader to eventually use ReadBuf, and the slow code is ReadBuf initializing the remaining uninitialized capacity. It does this by iterating over a slice, and that iteration is the slow bit. What I don't get here is why we need to initialize at all. That doesn't seem right.
WG-prioritization assigning highest priority since this looks a pretty visible runtime perf. regression (). If the assessment should be revised, please feel free to comment. label -I-prioritize +P-critical i-slow
I've tried bisecting with and feeding this command: . Regression seems to be in and confirm <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
:joy: I was so sure this wasn't my fault. More fool me for not bisecting it myself.
(This probably shows an opportunity to add a benchmark to the newly-established "runtime benchmarks" (rather than the compilation-time benchmarks that has classically focused on...)
After sleeping on this, I realized that there's no real reason to expect the worlds-worst-memset code which is the source of the slowdown to be totally optimized out with . And of course it isn't. This is also a substantial regression with optimizations.


Question: // Each call to `fill_buf` sets `filled` to indicate how many bytes at the start of `buf` are // initialized with bytes from a read. filled: usize, <ins> // This is the max number of bytes returned across all `fill_buf` calls. We track this so that we // can accurately tell `read_buf` how many bytes of buf are initialized, to bypass as much of its // defensive initialization as possible. Note that while this often the same as `filled`, it // doesn't need to be. Calls to `fill_buf` are not required to actually fill the buffer, and // omitting this is a huge perf regression for `Read` impls that do not. initialized: usize, </ins> } impl Buffer { #[inline] pub fn with_capacity(capacity: usize) -> Self { let buf = Box::new_uninit_slice(capacity); <del> Self { buf, pos: 0, filled: 0 } </del> <ins> Self { buf, pos: 0, filled: 0, initialized: 0 } </ins> } #[inline]

Here's a version of the original program that's touched up a bit: On 1.63 I see runtime ~0.43 s, and on 1.64 ~4.8 s. So we have a slowdown of around 10x, though I suspect that number could be ratcheted up higher.
claim
Awesome, thanks for the really quick fix!


Question: item.id, span, item.name, <del> item.node.descriptive_variant() </del> <ins> item.node.descriptive_variant(), "used", </ins> ); } else { // Only continue if we didn't warn

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


Question: .expect("failed to read src/version"); let version = version.trim(); <del> let bootstrap_out = std::env::current_exe() </del> <ins> let mut bootstrap_out = std::env::current_exe() </ins> .expect("could not determine path to running process") .parent() .unwrap() .to_path_buf(); <ins> // Since bootstrap is hardlink to deps/bootstrap-*, Solaris can sometimes give // path with deps/ which is bad and needs to be avoided. if bootstrap_out.ends_with("deps") { bootstrap_out.pop(); } </ins> if !bootstrap_out.join(exe("rustc", config.build)).exists() && !cfg!(test) { // this restriction can be lifted whenever https://github.com/rust-lang/rfcs/pull/3028 is implemented panic!(

Rust 1.70 build on Solaris sometimes files on some machines: I wonder whether it can do something with: ?!
are you running in parallel? that's not supported on solaris (you made the PR removing the build locking IIRC).
I see it does: . I think I should look once again if it's possible make to use fcntl locking (as it's now in `rustix... You can close the bug. Thank you!
Adding reference to main proble - isn't supported on Solaris due missing syscall).
I'm confused now. I have seen the same error even with (just one ocurance, not two as mentioned above). Also tried to dig closely how locking works and put into some debug prints with process id and lock file name. But later when I was inspecting still running process it didn't have any lock file open. No file descriptor no lock?!
did you clear the cache before running ? if the build directory gets into an inconsistent state we don't recover it automatically. i don't know what's going on with fd-lock, but the file that bootstrap locks is .
Everything is removed before new build...
exactly what command are you running and what is your
If I see it right, lock file is created/opened here: and the file descriptor for the lock file is closed on block exit here: Isn't it mean that locking isn't working even on Linux?
no, it's declared outside the block
Right. Unfortunatelly version 1.70.0 hasn't fix for this (my) regression. And the declaration is still insde the block.
we do not support old versions of rust. the only supported release is the latest stable release.
Isn't version 1.70.0 latest stable version? I'm just curious.
yes, you're right. i'm sorry. i think you should ask someone else for help on this issue. i am having trouble focusing today.
I run: and then: Where on some systems helps to run while on others it breaks it. When I look into the directory where rustc should be present:
i'm not sure why this is looking in . can you verify that exists? i wonder if is a hard-link to and that confuses on solaris.
It does: It's hardling. When I remove the asserion the build passes.


Question: .expect("failed to read src/version"); let version = version.trim(); <del> let bootstrap_out = std::env::current_exe() </del> <ins> let mut bootstrap_out = std::env::current_exe() </ins> .expect("could not determine path to running process") .parent() .unwrap() .to_path_buf(); <ins> // Since bootstrap is hardlink to deps/bootstrap-*, Solaris can sometimes give // path with deps/ which is bad and needs to be avoided. if bootstrap_out.ends_with("deps") { bootstrap_out.pop(); } </ins> if !bootstrap_out.join(exe("rustc", config.build)).exists() && !cfg!(test) { // this restriction can be lifted whenever https://github.com/rust-lang/rfcs/pull/3028 is implemented panic!(

It wasn't true. It just didnt' hit the problem when the code was rebuilt. Now I'm trying following: It must execute sometime deps/bootstrap-[hash] instead of just bootstrap.


Question: } else { "items from traits can only be used if the trait is implemented and in scope" }); <del> let mut msg = format!( </del> <ins> let message = |action| format!( </ins> "the following {traits_define} an item `{name}`, perhaps you need to {action}  {one_of_them}:", traits_define = if candidates.len() == 1 {

The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!


Question: <ins> #![crate_type="lib"] fn x<'a>(x: &mut 'a i32){} //~ ERROR lifetime must precede `mut` macro_rules! mac { ($lt:lifetime) => { fn w<$lt>(w: &mut $lt i32) {} //~^ ERROR lifetime must precede `mut` } } mac!('a); // avoid false positives fn y<'a>(y: &mut 'a + Send) { //~^ ERROR expected a path on the left-hand side of `+`, not `&mut 'a` //~| WARNING trait objects without an explicit `dyn` are deprecated //~| ERROR at least one trait is required for an object type let z = y as &mut 'a + Send; //~^ ERROR expected value, found trait `Send` //~| WARNING trait objects without an explicit `dyn` are deprecated } </ins>

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


Question: // Do not ask for a passphrase while manually testing let mut passphrase = String::new(); if should_sign { <del> // `x.py` passes the passphrase via stdin. </del> t!(io::stdin().read_to_string(&mut passphrase)); }

Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.


Question: <ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-102335-ty.rs:2:17 | LL |     type A: S<C<i32 = u32> = ()>; |                 ^^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </ins>

I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


Question: ) - visited elif item["kind"] == "variant": if item["inner"]["variant_kind"] == "tuple": <del> for ty in item["inner"]["variant_inner"]: check_type(ty) </del> <ins> for field_id in filter(None, item["inner"]["variant_inner"]): work_list.add(field_id) </ins> elif item["inner"]["variant_kind"] == "struct": <del> work_list |= set(item["inner"]["variant_inner"]) - visited </del> <ins> work_list |= set(item["inner"]["variant_inner"]["fields"]) - visited </ins> elif item["kind"] in ("function", "method"): check_generics(item["inner"]["generics"]) check_decl(item["inner"]["decl"])

At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:


Question: // If this is due to a block, then maybe we forgot a `return`/`break`. if due_to_block && let Some(expr) = expression <del> && let Some((parent_fn_decl, parent_id)) = fcx .tcx .hir() .parent_iter(block_or_return_id) .find_map(|(_, node)| Some((node.fn_decl()?, node.associated_body()?.0))) </del> <ins> && let Some(parent_fn_decl) = fcx.tcx.hir().fn_decl_by_hir_id(fcx.tcx.local_def_id_to_hir_id(fcx.body_id)) </ins> { fcx.suggest_missing_break_or_return_expr( &mut err,

<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)', 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [checkwellformed] checking that is well-formed --
fyi


Question: tcx.sess.span_err(span, "`..` cannot be used in union patterns"); } } else if !etc { <del> let unmentioned_fields = variant.fields .iter() .map(|field| field.ident.modern()) .filter(|ident| !used_fields.contains_key(&ident)) .collect::<Vec<_>>(); </del> if unmentioned_fields.len() > 0 { let field_names = if unmentioned_fields.len() == 1 { format!("field `{}`", unmentioned_fields[0])

With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .


Question: runtest(&args[0]); } } <del> // See issue 28218 #[cfg(all(windows, target_arch = "x86"))] fn main() {} </del>

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


Question: struct $crate {} //~ ERROR expected identifier, found reserved identifier `$crate` } <del> use $crate; // OK //~^ WARN `$crate` may not be imported </del> <ins> use $crate; //~ ERROR `$crate` may not be imported </ins> use $crate as $crate; //~ ERROR expected identifier, found reserved identifier `$crate` <del> //~^ WARN `$crate` may not be imported </del> <ins> //~^ ERROR `$crate` may not be imported </ins> } }

The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.


Question: if let Some(ty) = crate::types::repr_nullable_ptr(cx, adt, ckind) { ty == primitive } else { <del> compare_layouts(a, b) </del> <ins> compare_layouts(a, b).unwrap_or(false) </ins> } } // Otherwise, just compare the layouts. This may fail to lint for some // incompatible types, but at the very least, will stop reads into // uninitialised memory. <del> _ => compare_layouts(a, b), </del> <ins> _ => compare_layouts(a, b).unwrap_or(false), </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<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc for ClashingExternDeclarations in backtrace.
claim
Thank you for fixing it! There is nothing better than software with only a few open issues.
Not a problem! Thank you for the report, and especially for taking the time to make a minimal example :)


Question: } pub enum timezone {} <ins> pub type sighandler_t = size_t; </ins> } pub mod bsd44 { use libc::types::os::arch::c95::{c_char, c_int, c_uint};

Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from


Question: UniqueBorrow, /// AddressOf for *const pointer. AddressOf, <ins> /// PlaceMention statement. /// /// This statement is executed as a check that the `Place` is live without reading from it, /// so it must be considered as a non-mutating use. PlaceMention, </ins> /// Used as base for another place, e.g., `x` in `x.y`. Will not mutate the place. /// For example, the projection `x.y` is not marked as a mutation in these cases: /// ```ignore (illustrative)

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy


Question: # Explicitly disabling ICE dump export RUSTC_ICE=0 $RUSTC src/lib.rs -Z treat-err-as-bug=1 1>$TMPDIR/rust-test-disabled.log 2>&1 <del> should_be_empty_tmp=$(ls -l $TMPDIR/rustc-ice-*.txt | wc -l) should_be_empty_dot=$(ls -l ./rustc-ice-*.txt | wc -l) </del> <ins> should_be_empty_tmp=$(ls -l $TMPDIR/rustc-ice-*.txt 2>/dev/null | wc -l) should_be_empty_dot=$(ls -l ./rustc-ice-*.txt 2>/dev/null | wc -l) </ins> echo "#### ICE Dump content:" echo $content

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


Question: /// If you need a [`&str`] instead of a `String`, consider /// [`str::from_utf8`]. /// <del> /// The inverse of this method is [`as_bytes`]. </del> <ins> /// The inverse of this method is [`into_bytes`]. </ins> /// /// # Errors ///

This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?


Question: <ins> //@ run-rustfix #![allow(unused_mut)] use std::borrow::{Borrow, BorrowMut}; use std::convert::{AsMut, AsRef}; struct Bar; impl AsRef<Bar> for Bar { fn as_ref(&self) -> &Bar { self } } impl AsMut<Bar> for Bar { fn as_mut(&mut self) -> &mut Bar { self } } fn foo<T: AsRef<Bar>>(_: T) {} fn qux<T: AsMut<Bar>>(_: T) {} fn bat<T: Borrow<T>>(_: T) {} fn baz<T: BorrowMut<T>>(_: T) {} pub fn main() { let bar = Bar; foo(&bar); let _baa = bar; //~ ERROR use of moved value let mut bar = Bar; qux(&mut bar); let _baa = bar; //~ ERROR use of moved value let bar = Bar; bat(&bar); let _baa = bar; //~ ERROR use of moved value let mut bar = Bar; baz(&mut bar); let _baa = bar; //~ ERROR use of moved value } </ins>

... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :


Question: use foo::bar; foo::bar(); //~ ERROR: unnecessary qualification bar(); <ins> let _ = || -> Result<(), ()> { try!(Ok(())); Ok(()) }; // issue #37345 macro_rules! m { () => { $crate::foo::bar(); } } m!(); // issue #37357 </ins> }

When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .


Question: TyKind::Path(ref qself, ref path) => { self.diagnostic_metadata.current_type_path = Some(ty); self.smart_resolve_path(ty.id, qself.as_ref(), path, PathSource::Type); <ins> // Check whether we should interpret this as a bare trait object. if qself.is_none() && let Some(partial_res) = self.r.partial_res_map.get(&ty.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { // This path is actually a bare trait object.  In case of a bare `Fn`-trait // object with anonymous lifetimes, we need this rib to correctly place the // synthetic lifetimes. let span = ty.span.shrink_to_lo().to(path.span.shrink_to_lo()); self.with_generic_param_rib( &[], NormalRibKind, LifetimeRibKind::Generics { binder: ty.id, kind: LifetimeBinderKind::PolyTrait, span, }, |this| this.visit_path(&path, ty.id), ); self.diagnostic_metadata.current_type_path = prev_ty; return; } </ins> } TyKind::ImplicitSelf => { let self_ty = Ident::with_dummy_span(kw::SelfUpper);

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code with : I expected to see only warning without error, like this: Instead, this happened (extra error E0521 emitted, which is incorrect): If I add in line 3, it compiles without any error or warning: So the E0521 error emitted by the compiler is incorrect. The test code using should only produce warnings without an error. It most recently worked on: 1.63.0-nightly ( 2022-05-18) </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
labels:+T-compiler
label A-diagnostics
labels: +regression-from-stable-to-nightly
label -regression-untriaged Bisection: regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: that’s , cc
Seems like, possibly, the code without the explicit (incorrectly) desugars to rather than Edit: Or perhaps it incorrectly desugars to
Here’s another kind of code example that reproduces the issue Which does confirm the idea that this appears to be interpreted like , rather than which would be correct.
WG-prioritization assigning priority (). label -I-prioritize +P-critical


Question: TyKind::Path(ref qself, ref path) => { self.diagnostic_metadata.current_type_path = Some(ty); self.smart_resolve_path(ty.id, qself.as_ref(), path, PathSource::Type); <ins> // Check whether we should interpret this as a bare trait object. if qself.is_none() && let Some(partial_res) = self.r.partial_res_map.get(&ty.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { // This path is actually a bare trait object.  In case of a bare `Fn`-trait // object with anonymous lifetimes, we need this rib to correctly place the // synthetic lifetimes. let span = ty.span.shrink_to_lo().to(path.span.shrink_to_lo()); self.with_generic_param_rib( &[], NormalRibKind, LifetimeRibKind::Generics { binder: ty.id, kind: LifetimeBinderKind::PolyTrait, span, }, |this| this.visit_path(&path, ty.id), ); self.diagnostic_metadata.current_type_path = prev_ty; return; } </ins> } TyKind::ImplicitSelf => { let self_ty = Ident::with_dummy_span(kw::SelfUpper);

ndarray 0.9.1 compiles with rustc 1.61.0 but not with rustc 1.64.0-nightly ( 2022-06-27). Put this into a of a new project: rustc stable <= 1.61.0 compiles the crate fine, rustc nightly gives the following error: modify labels: +regression-from-stable-to-nightly -regression-untriaged
Just adding a note. The issue seems to be an old version of that used to use back in v0.9.1 <details</detailsThe crate from v0.13.0 (released in sept. 2019) compiles fine also on latest Rust nightly
bisection seems to point to commit cc searched nightlies: from nightly-2022-04-01 to nightly-2022-06-28 regressed nightly: nightly-2022-06-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details(unsure if this regression may hit other more recent crates)
I've been suspecting this bug for a few days, but unable to reproduce it. I think I have a patch, will confirm once I manage to MCVE.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: <ins> error[E0382]: use of moved value: `t` --> $DIR/issue-67123.rs:2:13 | LL | fn foo<T>(t: T) { |        - help: consider restricting this bound: `T: Copy` LL |     || { t; t; }; |          -  ^ value used here after move |          | |          value moved here | = note: move occurs because `t` has type `T`, which does not implement the `Copy` trait error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>

I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be


Question: // There was a previous subslice pattern; make sure we don't allow more. let rest_span = match pat.kind { PatKind::Rest => Some(pat.span), <del> PatKind::Ident(.., Some(ref sub)) if sub.is_rest() => { // The `HirValidator` is merciless; add a `_` pattern to avoid ICEs. after.push(self.pat_wild_with_node_id_of(pat)); </del> <ins> PatKind::Ident(ref bm, ident, Some(ref sub)) if sub.is_rest() => { // #69103: Lower into `binding @ _` as above to avoid ICEs. after.push(lower_rest_sub(self, pat, bm, ident, sub)); </ins> Some(sub.span) } _ => None,

The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:


Question: // in `SpecialCasing.txt`, // so hard-code it rather than have a generic "condition" mechanism. // See https://github.com/rust-lang/rust/issues/26035 <del> let out_len = self.len() - rest.len(); let sigma_lowercase = map_uppercase_sigma(&self, i + out_len); </del> <ins> let sigma_lowercase = map_uppercase_sigma(self, prefix_len + i); </ins> s.push(sigma_lowercase); } else { match conversions::to_lower(c) {

I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.


Question: // in `SpecialCasing.txt`, // so hard-code it rather than have a generic "condition" mechanism. // See https://github.com/rust-lang/rust/issues/26035 <del> let out_len = self.len() - rest.len(); let sigma_lowercase = map_uppercase_sigma(&self, i + out_len); </del> <ins> let sigma_lowercase = map_uppercase_sigma(self, prefix_len + i); </ins> s.push(sigma_lowercase); } else { match conversions::to_lower(c) {

The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.


Question: install_fatal_error_handler(FatalErrorHandler); } <ins> extern "C" void LLVMRustDisableSystemDialogsOnCrash() { sys::DisableSystemDialogsOnCrash(); } </ins> extern "C" char *LLVMRustGetLastError(void) { char *Ret = LastError; LastError = nullptr;

The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.


Question: // We special case `#[derive(_)]n` and other attribute suggestions, because those // are the ones where context is most useful. let file_lines = sm <del> .span_to_lines(span.primary_span().unwrap().shrink_to_hi()) </del> <ins> .span_to_lines(parts[0].span.shrink_to_hi()) </ins> .expect("span_to_lines failed when emitting suggestion"); let line_num = sm.lookup_char_pos(parts[0].span.lo()).line; if let Some(line) = file_lines.file.get_line(line_num - 1) {

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I have the following code, split into two files: This code, as expected, produces , shown below. However, the help message at the bottom of the error appears to be referencing line 2 in , while displaying the filename , thus suggesting we add the annotation to a comment in . It should instead point to the in . <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The issue is that in , the span we use to look up the file/line mapper is the primary span of the message, i.e. the error in


Question: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>

I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>

produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </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<strongBacktrace</strong</summary<p</p
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </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<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":


Question: <ins> error[E0689]: can't call method `rev` on type `usize` --> $DIR/issue-90315.rs:4:28 | LL |     for _i in 0..arr.len().rev() { |                            ^^^ can't call method `rev` on type `usize` | help: you must surround the range in parentheses to call its `rev` function | LL |     for _i in (0..arr.len()).rev() { |               +            + error[E0689]: can't call method `rev` on type `{integer}` --> $DIR/issue-90315.rs:12:20 | LL |     for i in 1..11.rev() { |                    ^^^ can't call method `rev` on type `{integer}` | help: you must surround the range in parentheses to call its `rev` function | LL |     for i in (1..11).rev() { |              +     + error[E0689]: can't call method `rev` on type `usize` --> $DIR/issue-90315.rs:18:21 | LL |     for i in 1..end.rev() { |                     ^^^ can't call method `rev` on type `usize` | help: you must surround the range in parentheses to call its `rev` function | LL |     for i in (1..end).rev() { |              +      + error[E0689]: can't call method `rev` on type `usize` --> $DIR/issue-90315.rs:23:27 | LL |     for i in 1..(end + 1).rev() { |                           ^^^ can't call method `rev` on type `usize` | help: you must surround the range in parentheses to call its `rev` function | LL |     for i in (1..(end + 1)).rev() { |              +            + error[E0689]: can't call method `is_empty` on type `usize` --> $DIR/issue-90315.rs:28:21 | LL |     if 1..(end + 1).is_empty() { |                     ^^^^^^^^ can't call method `is_empty` on type `usize` | help: you must surround the range in parentheses to call its `is_empty` function | LL |     if (1..(end + 1)).is_empty() { |        +            + error[E0308]: mismatched types --> $DIR/issue-90315.rs:28:8 | LL |     if 1..(end + 1).is_empty() { |        ^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found struct `std::ops::Range` | = note: expected type `bool` found struct `std::ops::Range<{integer}>` error[E0689]: can't call method `is_sorted` on type `usize` --> $DIR/issue-90315.rs:34:21 | LL |     if 1..(end + 1).is_sorted() { |                     ^^^^^^^^^ can't call method `is_sorted` on type `usize` | help: you must surround the range in parentheses to call its `is_sorted` function | LL |     if (1..(end + 1)).is_sorted() { |        +            + error[E0308]: mismatched types --> $DIR/issue-90315.rs:34:8 | LL |     if 1..(end + 1).is_sorted() { |        ^^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found struct `std::ops::Range` | = note: expected type `bool` found struct `std::ops::Range<{integer}>` error[E0689]: can't call method `take` on type `{integer}` --> $DIR/issue-90315.rs:40:26 | LL |     let _res: i32 = 3..6.take(2).sum(); |                          ^^^^ can't call method `take` on type `{integer}` | help: you must surround the range in parentheses to call its `take` function | LL |     let _res: i32 = (3..6).take(2).sum(); |                     +    + error[E0308]: mismatched types --> $DIR/issue-90315.rs:40:21 | LL |     let _res: i32 = 3..6.take(2).sum(); |               ---   ^^^^^^^^^^^^^^^^^^ expected `i32`, found struct `std::ops::Range` |               | |               expected due to this | = note: expected type `i32` found struct `std::ops::Range<{integer}>` error[E0689]: can't call method `sum` on type `{integer}` --> $DIR/issue-90315.rs:45:26 | LL |     let _sum: i32 = 3..6.sum(); |                          ^^^ can't call method `sum` on type `{integer}` | help: you must surround the range in parentheses to call its `sum` function | LL |     let _sum: i32 = (3..6).sum(); |                     +    + error[E0308]: mismatched types --> $DIR/issue-90315.rs:45:21 | LL |     let _sum: i32 = 3..6.sum(); |               ---   ^^^^^^^^^^ expected `i32`, found struct `std::ops::Range` |               | |               expected due to this | = note: expected type `i32` found struct `std::ops::Range<{integer}>` error[E0689]: can't call method `rev` on type `usize` --> $DIR/issue-90315.rs:53:21 | LL |     for _a in a..=b.rev() { |                     ^^^ can't call method `rev` on type `usize` | help: you must surround the range in parentheses to call its `rev` function | LL |     for _a in (a..=b).rev() { |               +     + error[E0689]: can't call method `contains` on type `{integer}` --> $DIR/issue-90315.rs:58:21 | LL |     let _res = ..10.contains(3); |                     ^^^^^^^^ can't call method `contains` on type `{integer}` | help: you must surround the range in parentheses to call its `contains` function | LL |     let _res = (..10).contains(3); |                +    + error[E0599]: no method named `error_method` found for type `usize` in the current scope --> $DIR/issue-90315.rs:62:15 | LL |     if 1..end.error_method() { |               ^^^^^^^^^^^^ method not found in `usize` error[E0308]: mismatched types --> $DIR/issue-90315.rs:62:8 | LL |     if 1..end.error_method() { |        ^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found struct `std::ops::Range` | = note: expected type `bool` found struct `std::ops::Range<{integer}>` </ins> error[E0599]: `usize` is not an iterator <del> --> $DIR/issue-90315.rs:3:26 </del> <ins> --> $DIR/issue-90315.rs:68:18 </ins> | <del> LL |   for _i in 0..arr.len().rev() { |                          ^^^ `usize` is not an iterator </del> <ins> LL |     let _res = b.take(1)..a; |                  ^^^^ `usize` is not an iterator </ins> | = note: the following trait bounds were not satisfied: `usize: Iterator` which is required by `&mut usize: Iterator` <del> error: aborting due to previous error </del> <ins> error[E0689]: can't call method `take` on ambiguous numeric type `{integer}` --> $DIR/issue-90315.rs:71:25 | LL |     let _res: i32 = ..6.take(2).sum(); |                         ^^^^ | help: you must specify a concrete type for this numeric value, like `i32` | LL |     let _res: i32 = ..6_i32.take(2).sum(); |                       ~~~~~ error[E0308]: mismatched types --> $DIR/issue-90315.rs:71:21 | LL |     let _res: i32 = ..6.take(2).sum(); |               ---   ^^^^^^^^^^^^^^^^^ expected `i32`, found struct `RangeTo` |               | |               expected due to this | = note: expected type `i32` found struct `RangeTo<_>` error: aborting due to 19 previous errors </ins> <del> For more information about this error, try `rustc --explain E0599`. </del> <ins> Some errors have detailed explanations: E0308, E0599, E0689. For more information about an error, try `rustc --explain E0308`. </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: [[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Minimal reproducible example, targeting the STM32G030F6 microcontroller: This panics in the computation of when built with: Note: this had to be tested with in the dev profile, in order to fit on the small flash size on the chip. This was confirmed on the and toolchains. <details<summaryGDB backtrace at the panic</summary</details<details<summaryFull to build</summary</details<details<summarymemory.x for the STM32G030F6</summary</details
Would it be possible to provide the output for this test case?
This is inside compiler-builtins. The arguments in the stack trace seem all sorts of wrong all over the place, though. But the shift width passed into is what you'd expect. An ABI mismatch, maybe?
To elaborate on my remark above: the LLVM IR will only reveal a plain instruction, which becomes a libcall only in codegen. To the issue author: can you please also post the exact command you're building? I'm not able to reproduce a similar issue when using a based approach – in particular I see many more functions being inlined away, functions which in your case don't appear to be. This is what I was trying:
Cortex-M0+ uses , which is also shipped via rustup
Hm, I cannot reproduce inside QEMU (using , steps described below), but maybe I'm missing something (maybe the error only shows up on the real hardware and not in QEMU). Please correct me, if I'm wrong. <details<summaryReproduction</summary</details
Sorry, I will put together a package that fully demonstrates it and upload a tarball later today. I'll also provide the LLVM and executable output. To be clear, I wasn't building using any direct invocation of rustc, just with cargo.
So I managed to simplify the minimal example further a bit, as it turns out that simply panics too, since the formatter for integers involves multiplication. This is reflected in the following attachments. I have tested these on a live STM32G030 chip; the GDB backtrace is from that (over openocd through the SWD port). I don't consider myself knowledgable enough with QEMU to try to reproduce it there.


Question: [[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Complete example: Executable: <details<summaryGDB backtrace at panic</summary</details<details<summaryLLVM IR</summary</details
does it also reproduce on Rust stable (or beta)? Just to understand here if it's a regression or this issue has "always" been here (I suspect the latter)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Good thinking... I just tested it on stable and it appears to not be present there (or at least not with all else equal). I confirmed the issue on again just to be sure I didn't change anything else. I'm not sure if there's a good way to bisect the rust toolchain to find the regression? If there is I may be able to script it to see if GDB reports a panic and use that. Of course QEMU would be better-suited for that, so I may try to repro in it as well.
cool then probably we can try to find the regression To bisect we use , it will download nightlies in a range of time and bisect them to find where the regression starts. You'll need to download the Rust sources beforehand (this repo) and then run it like: should be 755 and something like: cargo-bisect will then download nightlies. The first one must not reproduce the issue, so if it does, move a bit back in time until you hit one of the last good nightly. If everything goes well you should get an ouput similar to Thanks a lot for trying to bisect the issue! :-) label regression-from-stable-to-nightly
Here's the report: searched nightlies: from nightly-2021-04-01 to nightly-2021-06-05 regressed nightly: nightly-2021-05-15 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
That is a huge commit, but if it helps, I have a hunch that the regression may actually be in , since a) the version of it changed as part of that commit and b) that's where the implementaiton of this is.


Question: [[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

On the other hand, the connection to is weird. Before reporting the issue I did delve into the source but most of the arithmetic implementation stuff kinda went over my head unfortunately.
This is highly likely to slip into stable next week -- let's ping arm to at least get some more eyes on it (doesn't look like that was done yet).
Error: Parsing ping command in failed: ...'t ping arm' ' to at lea'... Please let know if you're having trouble with this bot.
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I can reproduce this on qemu. I'm not sure precisely what I'm doing differently to but I'm using the source tarball uploaded (plus a modified memory layout for the QEMU machine). Possibly in the cargo config would do it. From the last working rust commit bumping compiler-builtins to 0.1.40 (from 0.1.39) is enough to trigger this. Unfortunately, patching out compilerbuiltins to a local path (checked out to 0.1.39) also seems to reliably trigger it so I haven't been able to narrow down to a specific compilerbuiltins commit. Additionally I can't reproduce on , only v6.
That matches what I observed on real hardware as well.
54 stable will be built today and released on Thursday, this will unfortunately have to slip into stable :( The target is not tier 1 so this won't block the release, but it will be in the compatibility notes section.
Is the build process documented somewhere? Is it a highly optimized binary?
The build itself is done by our normal CI and the full release process is . The build doesn't take that long to finish though. The Release Team prepares the final release on Monday to be able to publish a pre-release on Monday evening, allowing testing from the wider community before the actual release goes out. It's possible to do a rebuild after Monday if critical issues are found and need to be fixed, but is not a Tier 1 target so a fix for this would likely not result in a rebuild, and would slip into 1.55.
Thanks!


Question: [[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

I noted that the python scripts use the aws cli instead of the excellent boto3 library. But probably the scripts are battle proof by now.
This is a bug in LLVM's expansion of 128-bit shifts: The 128-bit shift is expanded to a series of 64-bit shift via . Note how the shift value in is only masked with before being passed to . This means that the shift value passed to may be larger than 64, which is UB according to the specification for (shift value must be < 64).
A bisect on compiler-builtins leads to this commit as the incidental "cause": Reverting it does fix this bug if a quick & dirty fix is wanted.
On second thought, I don't think this is an LLVM bug: it seems that the code calls with an out-of-range shift, but then doesn't actually use the result of that call in that case. I opened which should fix this, could someone test to see if this actually resolves the issue?
looks fixed to me. Nice work!