Question: NonZeroUsize::new(remaining).map_or(Ok(()), Err) } <ins> #[inline] unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> Self::Item { // SAFETY: The caller must provide an idx that is in bound of the remainder. unsafe { self.data.as_ptr().add(self.alive.start()).add(idx).cast::<T>().read() } } </ins> } #[stable(feature = "array_value_iter_impls", since = "1.40.0")]

<!-- 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: I expected to see this happen: same codegen or similar in performance Instead, this happened: array has way worse codegen <details<summaryAssembly</summary<p</p</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.64 <!-- Provide the version you are using that has the regression. --65 till now. Regressed in nightly-2022-08-13, maybe LLVM 15 ?: : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. -- modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WG-prioritization assigning priority (). cc since this regressed in the LLVM 15 update label -I-prioritize +P-medium +T-compiler
I've seen llvm doing these strange 1-byte-at-a-time "vectorizations" in other places too. This might be a more general problem. In this case we can probably paper over it by implementing TrustedRandomAccess for the array iter.
Unfortunately, the array iterator is fundamentally worse right now, because indexing into it -- a fundamental part of being a by-value array iterator -- keeps it from SRoAing and thus doesn't optimize well. This is why when I was making better I ended up making to not have to use . Sadly, for the foreseeable future you're better off using the "weaker" slice iterator when you can.
My guess is that the SROA is missing something in the opaque pointer mode.


Question: NonZeroUsize::new(remaining).map_or(Ok(()), Err) } <ins> #[inline] unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> Self::Item { // SAFETY: The caller must provide an idx that is in bound of the remainder. unsafe { self.data.as_ptr().add(self.alive.start()).add(idx).cast::<T>().read() } } </ins> } #[stable(feature = "array_value_iter_impls", since = "1.40.0")]

claim
It's not about vectorization. This optimization can be restored by using . But highly unrecommended. Upstream issue:
The upstream issue is closed. claim


Question: <ins> error: named argument `world` is not used by name --> $DIR/sugg_with_positional_args_and_debug_fmt.rs:6:28 | LL |     println!("hello {:?}", world = "world"); |                     ----   ^^^^^ this named argument is referred to by position in formatting string |                     | |                     this formatting argument uses named argument `world` by position | note: the lint level is defined here --> $DIR/sugg_with_positional_args_and_debug_fmt.rs:3:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(named_arguments_used_positionally)]` implied by `#[deny(warnings)]` help: use the named argument by name to avoid ambiguity | LL |     println!("hello {world:?}", world = "world"); |                      +++++ error: aborting due to previous error </ins>

The suggestion that rustc gives is incorrect and seems to not take into account what characters are in the format argument. I tried this code: I expected to see this happen: Instead, this happened: Using beta.2/nightly : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -C-bug +A-diagnostics +T-compiler
claim


Question: n => { let m = cmp::min(n, self.steals); self.steals -= m; <del> self.cnt.fetch_add(n - m, atomics::SeqCst); </del> <ins> self.bump(n - m); </ins> } } assert!(self.steals >= 0); } <ins> self.steals += 1; </ins> Ok(data) }

PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.


Question: <del> // no-prefer-dynamic </del> static mut DROP_RAN: bool = false; struct Foo;

Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?


Question: <del> // no-prefer-dynamic </del> // ignore-cloudabi // ignore-emscripten // ignore-sgx no processes


Question: <ins> // run-rustfix fn wat<T: Clone>(t: &T) -> T { t.clone() //~ ERROR E0308 } #[derive(Clone)] struct Foo; fn wut(t: &Foo) -> Foo { t.clone() //~ ERROR E0308 } fn main() { wat(&42); wut(&Foo); } </ins>

This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"


Question: let it = xs.iter_mut().map(|x| *x = 1).enumerate().zip(&ys); it.count(); } <del> assert_eq!(&xs, &[1, 1, 1, 1, 1, 0]); </del> <ins> let length_aware =  &xs == &[1, 1, 1, 1, 0, 0]; let probe_first = &xs == &[1, 1, 1, 1, 1, 0]; // either implementation is valid according to zip documentation assert!(length_aware || probe_first); </ins> } #[test]


Question: let it = xs.iter_mut().map(|x| *x = 1).enumerate().zip(&ys); it.count(); } <del> assert_eq!(&xs, &[1, 1, 1, 1, 1, 0]); </del> <ins> let length_aware =  &xs == &[1, 1, 1, 1, 0, 0]; let probe_first = &xs == &[1, 1, 1, 1, 1, 0]; // either implementation is valid according to zip documentation assert!(length_aware || probe_first); </ins> } #[test]


Question: <del> error: unmatched angle bracket </del> <ins> error: expected one of `!`, `+`, `::`, `;`, `where`, or `{`, found `>` </ins> --> $DIR/issue-24780.rs:5:23 | LL | fn foo() -> Vec<usize>> { <del> |                       ^^ help: remove extra angle bracket </del> <ins> |                       ^ expected one of `!`, `+`, `::`, `;`, `where`, or `{` </ins> error: aborting due to previous error

Alternate title: "Rust is literally C++" As of nightly-2020-10-29, rustc fails to parse the following code. The previous nightly and all past stable releases since 1.0.0 are not affected. The relevant commit range is
Mentioning because "Tweak invalid  header and body parsing" sounds extremely relevant.
Assigning and removing as in the prioritization working group.
searched nightlies: from nightly-2020-10-27 to nightly-2020-10-29 regressed nightly: nightly-2020-10-29 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsYeah, seems likely that is the culprit.
Yep, this was me :-/ I'll have a PR up in the next hour.


Question: let buildpath = fs::connect(_path, "/test"); need_dir(buildpath); #debug("Testing: %s -> %s", cf, buildpath); <del> let p = run::program_output("rustc", ["--out-dir", buildpath, "--test", cf]); </del> <ins> let p = run::program_output(rustc_sysroot(), ["--out-dir", buildpath, "--test", cf]); </ins> if p.status != 0 { error(#fmt["rustc failed: %dn%sn%s", p.status, p.err, p.out]); ret;

cargo is relying on the to find rustc, but if one runs cargo with , cargo will error out with the unhelpful: cargo should detect this and return a proper error message for this. A proper workaround for this is to make sure that has an absolute path to the binaries set, as in: It needs to be absolute because cargo does a chdir to the build directory, which would break a relative path.
We have a function, that cargo can use to determine the path to itself, then use to launch the corresponding rustc.


Question: let buildpath = fs::connect(_path, "/test"); need_dir(buildpath); #debug("Testing: %s -> %s", cf, buildpath); <del> let p = run::program_output("rustc", ["--out-dir", buildpath, "--test", cf]); </del> <ins> let p = run::program_output(rustc_sysroot(), ["--out-dir", buildpath, "--test", cf]); </ins> if p.status != 0 { error(#fmt["rustc failed: %dn%sn%s", p.status, p.err, p.out]); ret;

Instead of just saying the key can't be verified, explain why.
Yeah, it should also not fail! Missing gpg is a warning condition, not an error condition.


Question: args.push(~"-dynamiclib"); args.push(~"-Wl,-dylib"); // FIXME (#9639): This needs to handle non-utf8 paths <del> args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); </del> <ins> if !sess.opts.no_rpath { args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); } </ins> } else { args.push(~"-shared") }

Currently (something after 0.5) rustc (IIUIC) is using rpaths to point libs and binaries to the appropriate locations. This is problematic when rustc and the other libs/bins are package e.g. for Fedora. The rpath usage should be made optional - can be used instead - and LDLIBRARYPATH.
Why is this problematic for packaging? Is it because the rpath values end up with the wrong values? Each crate's rpath has several values, one of which is supposed to be the final installation location (controlled with ). Can we just provide more control over which locations are used during rpathing?
In general Fedora recommends to not use rpaths [0], because the paths are hardcoded in the binary. Fedora preferres to point the dynamic linker to the appropriate paths [1]. But yes, we are more flexible about internal libraries - which the case is here. So yes, it would also help us if we could controll the rpath path (which goes a bit into the direction if issue ) [0] [1]
The following rpath is used in e.g. the cargo binary: The rpath referres to rpm's buildroot, where the lib won't stay (it will be instaled to ) Maybe the problem could adressed if the rpath would respect - but this could lead to problems at build time. Maybe LDLIBRARYPATH can be used to point to the correct dir's at build time, and the rpath can be used to point to the correct dir's at runtime. Just my 2ct - but you ar ethe expert :)
Thanks for those links. We do generate rpaths with the expectation that some of them will be invalidated by moving the binaries around. It's possible we could consider removing rpath, but it sure is nice to not think about dynamic loading when running binaries out of my build directory. We could easily add a flag to the configure script, to turn off the rpath for all the rust-provided libraries, with the assumption that package managers would modify during install. If we did that I feel like we would still want the installed rustc to generate rpaths with user-built libraries - otherwise the experience would be different depending on the rust installation. We could also just remove rpath completely - it doesn't work on windows anyway.


Question: args.push(~"-dynamiclib"); args.push(~"-Wl,-dylib"); // FIXME (#9639): This needs to handle non-utf8 paths <del> args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); </del> <ins> if !sess.opts.no_rpath { args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); } </ins> } else { args.push(~"-shared") }

Another thing to consider is that, if we just used rustpkg for all builds, and let rustpkg install all libraries at a known location, then we might be able to conveniently not use rpath while still doing the right thing at load time. Can user directories like be put into ?
Yes - I can fully understand how easy running rust in the build directory is when using rpaths :) For the build directory use case it should be possible to create wrappers for rustc and friends which use to point to the correct dirs. You mention thet some libs might reside in , could you explain the overall concept you are following with this? In general I'd expect libraries to appear in /lib, /usr/lib some and some private /usr/lib/myapp. There are also some xdg specs that specify and - but let usfirst see what you say about ~/.rustpkg. Oh, I don't think that ~/.rustpkg would be expanded correctly if put into
Just to summarize my thoughts: If rpath is used, the rpath path beeing used should only use directories below (to point to non-standard dirs containing libs relevant for a rust component). The rpath path should not point to any build-time dir. To include libraries at buildtime or when using the binaries in the build directory I'd suggest using wrappers (isn't autotools doing it like this?) which set appropriately.
Any follow up thoughts?
Our package manager will by default not be installing libraries to a system location and will instead put them in the user's directory, . This doesn't seem out of the ordinary to me; consider cabal, etc. The behavior you recommend requires some deep changes to how Rust works, so need to be considered carefully. Does the current behavior prevent packaging in Fedora, and is there a minimal change we can make to unblock packaging? You'll probably be interested in this subject.
Thanks for the rustpkg explanation. Do I understand that rustpkg will create binaries and libs with rpaths pointing to the user's specific rustpkg dir ? My feeling is that this user specific rpaths should be configurable at build time. The use case is obviously when the binary or lib is going to be installed systemwide. The only rpath exception is the rpath pointing to the system wide package specific libdir (e.g. ).


Question: args.push(~"-dynamiclib"); args.push(~"-Wl,-dylib"); // FIXME (#9639): This needs to handle non-utf8 paths <del> args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); </del> <ins> if !sess.opts.no_rpath { args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); } </ins> } else { args.push(~"-shared") }

I think that I'll spend a bit more time with looking at and and might get a better feeling for the problem. Btw.: I noted that the libdir isn't configurabel. Fedora for example keeps x86_64 libs in (/usr)?/lib64, and i686 in (/usr)/lib. IIUIC this is currently not possible with rust as the libs will be installed to /usr/lib/arch-specific-path
The point about libdir is well taken and I updated . I am not entirely sure how rustpkg does it's build now or how and intend for it to work, but based on the current language design I would expect that, yes, binaries installed to would have rpaths pointing there. Currently there are several rpaths configured for each linked library so that they hopefully fall back to something useful when the libraries are moved around during install or during the bootstrapping process, something like: The relative path to the library The absolute path to where the library was at build time The system installation path Under this scheme I would expect that would, when linking against libraries in , create rpaths to .
Yes, there are several rpaths used (seen in and ) and I'd say - even with looking at rust itself, without the packaging glasses on - that it should be configurable what rpaths are used. Maybe it should be an option of . As said, system wide binaries are the best example for binaries where you don't want to many rpaths - including no rpaths pointing to some user dir.
Please don't tag TJC :(
Sorry, TJC! Maybe it's time to give in and start working on Rust :) Seriously though, sorry. I'm sure it's a real PITA.
mentioned that this is a security issue, which I didn't realize. Debian also says .
By the way, it's possible to strip this with but it would be much nicer to not require a third party tool.
I generally wonder why you don't add a user-specific to to point to the user specific rustpkg dir instead of using rpath. That makes it much easier to cope with - and that would also be in par with (at least) the Fedora guidelines. And I suppose with Debian's too, as it's the common way. (See 3rd party java binaries. They modify the to point to some hidden dir in the userdir.)
We used to.


Question: args.push(~"-dynamiclib"); args.push(~"-Wl,-dylib"); // FIXME (#9639): This needs to handle non-utf8 paths <del> args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); </del> <ins> if !sess.opts.no_rpath { args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); } </ins> } else { args.push(~"-shared") }

Users kept forgetting and/or getting annoyed having to adjust it when running from a build dir. Rpaths made it possible to run foo/bar/rustc no matter which rustc you chose.
right. IIUIC - I always feel like a noob when it comes to autotools - autotools are generating wrappers for binaries which are created during a build process and moves the original binaries to hiddend irectories. The wrappers are then modifying the environment (setting env vars etc) to achieve the same goal (so e.g. that rustc can be run from the dev directory without messing with the env vars yourself). I wonder if this could help.
Okay, it's actually not autools which creates these wrappers but libtool:
Sorry, I didn't mean to imply a disinterest in fixing this better, just noting how it came to be. Also strongly disinterested in using libtool. Would prefer going back to telling users to set env vars.
How about defaulting to static linking (when it works)? Dynamic linking is valuable, but mostly for global installs handled by a package manager. Of course, if we end up with a bunch of tools using that would be wasteful. I think RPATH will just lead to confusion, and it's an easy security hole to leave open.
I would be very happy to get static linking working well enough to make it a default in many such cases. But we ought to do the right thing when linking dynamically too. Is rpath-using- considered acceptable? I.e. is it just the absolute paths that are problematic?
The absolute paths are the ones that can easily be a security issue, so isn't that bad. I would still rather avoid it for a globally installed package but it's easy enough to strip for people who don't need it and won't be an issue if you don't know about it (like the absolute path could be). Using the rpath could be a flag, but the absolute path should never be there.
Nominating for milestone 2: backwards compatible. (The choice of whether one needs to put a setting in or use some configure flag for certain systems, etc, seems like a backwards compatibility issue. Though maybe I misunderstand and these are issues only for people developing itself, not for clients of ?) It also could well be that this is more appropriately assocated with milestone 1: well-defined.


Question: args.push(~"-dynamiclib"); args.push(~"-Wl,-dylib"); // FIXME (#9639): This needs to handle non-utf8 paths <del> args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); </del> <ins> if !sess.opts.no_rpath { args.push(~"-Wl,-install_name,@rpath/" + out_filename.filename_str().unwrap()); } </ins> } else { args.push(~"-shared") }

I suspect and have a more concrete notion about this.
I don't have anything much to add to this despite it coming up for triage today. I think it has to be fixed still, I'm still happy to do it via whatever combination of static linking by default and use of is sufficient for packagers, and I haven't seen any clear movement on it in the meantime.
accepted for backwards-compatible milestone
I'm getting worried that we won't resolve this for 1.0. I agree this is important to fix. Here's my current suggestion: Modify the build system to once again set LDLIBRARYPATH/PATH to find the appropriate dynamic libraries. Add a flag to rustc to disable rpath Add a configure flag to disable rpathing the rust build itself. Packagers can use this to do whatever they want. With this logic the rust package itself could avoid rpath where distros have their own way of dealing with library paths. The rustc installed by these distros would still be rpathing user's crates for the sake of convenience. Is this an acceptable compromise or do distros want us to completely disable rpath? I'm afraid that doing so would provide an inconsistent developer experience depending on how rustc is acquired; if we need to do that then we instead must find a way to completely eliminate rpath.
If we start to just statically link everything by default then rpath becomes much less important and we can just say it's up to users to figure it out if they opt into dynamic linking.
I think we should completely remove absolute rpaths. It's okay to have $ORIGIN-based ones but it may not be a good default. I'm not sure what the answer is to that, but agree that static linking basically resolves this.
It doesn't appear that this is fully working. There are still rpaths in the binaries when configured with even though the flag for rustc does work. /usr/bin/rustc: RPATH=$ORIGIN/../lib:/build/rust-git/src/rust/x8664-unknown-linux-gnu/stage1/lib/rustlib/x8664-unknown-linux-gnu/lib:/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
What steps did you follow to having the rpath show up? I thought I double checked on linux that the configure flag worked, but I may have overlooked something.


Question: <ins> // issue: rust-lang/rust#125081 fn main() { let _: &str = 'β; //~^ ERROR expected `while`, `for`, `loop` or `{` after a label //~| ERROR mismatched types } </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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 [analysis] running analysis passes on this crate --
cc


Question: hir::ItemEnum(..)        | hir::ItemStruct(..)      | hir::ItemUnion(..)       => { <del> false </del> <ins> (false, false) </ins> } };

Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:


Question: <ins> // edition:2018 fn main() { use a::ModPrivateStruct; let Box { 0: _, .. }: Box<()>; //~ ERROR field `0` of let Box { 1: _, .. }: Box<()>; //~ ERROR field `1` of let ModPrivateStruct { 1: _, .. } = ModPrivateStruct::default(); //~ ERROR field `1` of } mod a { #[derive(Default)] pub struct ModPrivateStruct(u8, u8); } </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
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.


Question: <ins> extern crate alloc; #[cfg(test)] mod tests { #[test] fn something_alloc() { assert_eq!(Vec::<u32>::new(), Vec::<u32>::new()); } } </ins>

If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim


Question: <ins> extern crate alloc; #[cfg(test)] mod tests { #[test] fn something_alloc() { assert_eq!(Vec::<u32>::new(), Vec::<u32>::new()); } } </ins>

<!-- 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. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet.


Question: <ins> extern crate alloc; #[cfg(test)] mod tests { #[test] fn something_alloc() { assert_eq!(Vec::<u32>::new(), Vec::<u32>::new()); } } </ins>

Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim


Question: self.delegate.push_verify(origin, GenericKind::Alias(alias_ty), region, verify_bound); } <ins> #[instrument(level = "debug", skip(self))] </ins> fn substs_must_outlive( &mut self, substs: SubstsRef<'tcx>, origin: infer::SubregionOrigin<'tcx>, region: ty::Region<'tcx>, <ins> opt_variances: Option<&[ty::Variance]>, </ins> ) { let constraint = origin.to_constraint_category(); <del> for k in substs { </del> <ins> for (index, k) in substs.iter().enumerate() { </ins> match k.unpack() { GenericArgKind::Lifetime(lt) => { <del> self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); </del> <ins> let variance = if let Some(variances) = opt_variances { variances[index] } else { ty::Invariant }; if variance == ty::Invariant { self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); } </ins> } GenericArgKind::Type(ty) => { self.type_must_outlive(origin.clone(), ty, region, constraint);

Another regresssion of with a different failure path: It should be fixed by ignoring non-captured lifetimes in: cc label regression-from-stable-to-stable C-bug T-compiler T-types A-impl-trait
Note that fixing this issue is necessary for , but might not be sufficient. I'll investigate more...
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: self.delegate.push_verify(origin, GenericKind::Alias(alias_ty), region, verify_bound); } <ins> #[instrument(level = "debug", skip(self))] </ins> fn substs_must_outlive( &mut self, substs: SubstsRef<'tcx>, origin: infer::SubregionOrigin<'tcx>, region: ty::Region<'tcx>, <ins> opt_variances: Option<&[ty::Variance]>, </ins> ) { let constraint = origin.to_constraint_category(); <del> for k in substs { </del> <ins> for (index, k) in substs.iter().enumerate() { </ins> match k.unpack() { GenericArgKind::Lifetime(lt) => { <del> self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); </del> <ins> let variance = if let Some(variances) = opt_variances { variances[index] } else { ty::Invariant }; if variance == ty::Invariant { self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); } </ins> } GenericArgKind::Type(ty) => { self.type_must_outlive(origin.clone(), ty, region, constraint);

Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high


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

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


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

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


Question: "Force drop flag checks on or off"), trace_macros: bool = (false, parse_bool, "For every macro invocation, print its name and arguments"), <del> disable_nonzeroing_move_hints: bool = (false, parse_bool, "Force nonzeroing move optimization off"), </del> <ins> enable_nonzeroing_move_hints: bool = (false, parse_bool, "Force nonzeroing move optimization on"), </ins> } pub fn default_lib_output() -> CrateType {

It looks like that when a local variable is initialized in a loop and dropped in the same loop, the stack local drop flag for that local isn't reinitialized to "not dropped" when the loop runs after the first time. Concretely, this test passes on stable and fails on nightly right now: cc
Interestingly this slight variation on the above code does drop twice as expected:


Question: } } <del> fn no_such_field_err<T: Display>( </del> <ins> fn no_such_field_err( </ins> &self, <del> span: Span, field: T, expr_t: &ty::TyS<'_>, </del> <ins> field: Ident, expr_t: &'tcx ty::TyS<'tcx>, </ins> ) -> DiagnosticBuilder<'_> { <del> type_error_struct!( </del> <ins> let span = field.span; debug!("no_such_field_err(span: {:?}, field: {:?}, expr_t: {:?})", span, field, expr_t); let mut err = type_error_struct!( </ins> self.tcx().sess, <del> span, </del> <ins> field.span, </ins> expr_t, E0609, "no field `{}` on type `{}`", field, expr_t <del> ) </del> <ins> ); // try to add a suggestion in case the field is a nested field of a field of the Adt if let Some((fields, substs)) = self.get_field_candidates(span, &expr_t) { for candidate_field in fields.iter() { if let Some(field_path) = self.check_for_nested_field(span, field, candidate_field, substs, vec![]) { let field_path_str = field_path .iter() .map(|id| id.name.to_ident_string()) .collect::<Vec<String>>() .join("."); debug!("field_path_str: {:?}", field_path_str); err.span_suggestion_verbose( field.span.shrink_to_lo(), "one of the expressions' fields has a field of the same name", format!("{}.", field_path_str), Applicability::MaybeIncorrect, ); } } } err } fn get_field_candidates( &self, span: Span, base_t: Ty<'tcx>, ) -> Option<(&Vec<ty::FieldDef>, SubstsRef<'tcx>)> { debug!("get_field_candidates(span: {:?}, base_t: {:?}", span, base_t); let mut autoderef = self.autoderef(span, base_t); while let Some((base_t, _)) = autoderef.next() { match base_t.kind() { ty::Adt(base_def, substs) if !base_def.is_enum() => { let fields = &base_def.non_enum_variant().fields; // For compile-time reasons put a limit on number of fields we search if fields.len() > 100 { return None; } return Some((fields, substs)); } _ => {} } } None } /// This method is called after we have encountered a missing field error to recursively /// search for the field fn check_for_nested_field( &self, span: Span, target_field: Ident, candidate_field: &ty::FieldDef, subst: SubstsRef<'tcx>, mut field_path: Vec<Ident>, ) -> Option<Vec<Ident>> { debug!( "check_for_nested_field(span: {:?}, candidate_field: {:?}, field_path: {:?}", span, candidate_field, field_path ); if candidate_field.ident == target_field { Some(field_path) } else if field_path.len() > 3 { // For compile-time reasons and to avoid infinite recursion we only check for fields // up to a depth of three None } else { // recursively search fields of `candidate_field` if it's a ty::Adt field_path.push(candidate_field.ident.normalize_to_macros_2_0()); let field_ty = candidate_field.ty(self.tcx, subst); if let Some((nested_fields, _)) = self.get_field_candidates(span, &field_ty) { for field in nested_fields.iter() { let ident = field.ident.normalize_to_macros_2_0(); if ident == target_field { return Some(field_path); } else { let field_path = field_path.clone(); if let Some(path) = self.check_for_nested_field( span, target_field, field, subst, field_path, ) { return Some(path); } } } } None } </ins> } fn check_expr_index(

I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
Thank you.


Question: }, base_t, None); <ins> // Try to give some advice about indexing tuples. if let ty::TyTuple(_) = base_t.sty { let mut needs_note = true; // If the index is an integer, we can show the actual // fixed expression: if let hir::ExprLit(ref lit) = idx.node { if let ast::LitKind::Int(i, ast::LitIntType::Unsuffixed) = lit.node { let snip = fcx.tcx().sess.codemap().span_to_snippet(base.span); if let Ok(snip) = snip { err.span_suggestion(expr.span, "to access tuple elements, use tuple  indexing syntax as shown", format!("{}.{}", snip, i)); needs_note = false; } } } if needs_note { err.help("to access tuple elements, use tuple indexing  syntax (e.g. `tuple.0`)"); } } err.emit(); </ins> fcx.write_ty(id, fcx.tcx().types.err); } }

When trying to (erroneously) access members of a tuple using square brackets, rather than a period, the compiler gives the message " error: cannot index a value of type .... ". Particularly as a new user, it would be nice if the compiler could suggest something like "try using the syntax rather than <tuple[idx]." This isn't by any means a big issue, but it would help eliminate yet another search through the documentation.


Question: error[E0277]: the trait bound `NotDebugOrDisplay: Marker` is not satisfied <del> --> $DIR/overlap-marker-trait.rs:27:17 </del> <ins> --> $DIR/overlap-marker-trait.rs:28:17 </ins> | LL |     is_marker::<NotDebugOrDisplay>(); |                 ^^^^^^^^^^^^^^^^^ the trait `Marker` is not implemented for `NotDebugOrDisplay` | note: required by a bound in `is_marker` <del> --> $DIR/overlap-marker-trait.rs:15:17 </del> <ins> --> $DIR/overlap-marker-trait.rs:16:17 </ins> | LL | fn is_marker<T: Marker>() { } |                 ^^^^^^ required by this bound in `is_marker`

Not sure if we have a test for the following and rust #![feature(markertraitattr)] #[marker] trait Marker {} impl Marker for &' () {} impl Marker for &' () {} If not, we need to add them, since they would be important for special casing during canonicalization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can help add this test if needed. (Did not rustbot claim so as to not remove lcnr from assignee)
Sure :) would help out if nothing else
assign Rageking8
Error: Parsing assign command in failed: ...' Rageking8' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
assign
label +F-markertraitattr In case this needs to be indexed in the future.


Question: <ins> fn foo() { let x = Tr<A, A:>; //~^ ERROR expected one of `!`, `.`, `::`, `;`, `?`, `else`, `{`, or an operator, found `,` } fn main() {} </ins>

<!-- 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: on stable 1.78.0, this checks in 0.02 seconds. on beta 1.79.0-beta.3, this hangs somewhere in , I killed it after 5 minutes of no progress.
cc
Sharing the stack would be useful
:thinking: that doesn't really seem to be it
You need to switch to like thread 2 or 3 if you're doing this in gdb
it's not particularly deep, but it looks downstream of so I guess this must be it
Minimal:


Question: <ins> // revisions: min_const_fn const_fn // run-pass #![cfg_attr(const_fn, feature(const_fn))] trait ConstDefault { const DEFAULT: Self; } #[derive(PartialEq)] enum E { V(i32), W(usize), } impl ConstDefault for E { const DEFAULT: Self = Self::V(23); } impl ConstDefault for Option<i32> { const DEFAULT: Self = Self::Some(23); } impl E { const NON_DEFAULT: Self = Self::W(12); const fn local_fn() -> Self { Self::V(23) } } const fn explicit_qpath() -> E { let _x = <Option<usize>>::Some(23); <E>::W(12) } fn main() { assert!(E::DEFAULT == E::local_fn()); assert!(Option::DEFAULT == Some(23)); assert!(E::NON_DEFAULT == explicit_qpath()); } </ins>

The feature allows calling any expression of a tuple-like constructor in a : cc
Implemented on 2019-06-07 by in which was reviewed by
Is there anything else needs to be done to resolve this issue?
FCP and stabilization pull request.
Do you think you have time to write a report (e.g. in the style of ) and amend the reference after?
I propose that we stabilize . Tracking issue: Version target: 1.40 (2019-11-05 =beta, 2019-12-19 =stable). Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called : Consistency with other . This should also ensure that constructors implement traits and can be coerced to function pointers, if they are introduced. - Tests various syntactic forms, use in both and items, and constructors in both the current and extern crates. The case in should also get a test.
Thanks! Could you embed this report in a PR with the aforementioned test there as well? I'll FCP that PR.


Question: <ins> // revisions: min_const_fn const_fn // run-pass #![cfg_attr(const_fn, feature(const_fn))] trait ConstDefault { const DEFAULT: Self; } #[derive(PartialEq)] enum E { V(i32), W(usize), } impl ConstDefault for E { const DEFAULT: Self = Self::V(23); } impl ConstDefault for Option<i32> { const DEFAULT: Self = Self::Some(23); } impl E { const NON_DEFAULT: Self = Self::W(12); const fn local_fn() -> Self { Self::V(23) } } const fn explicit_qpath() -> E { let _x = <Option<usize>>::Some(23); <E>::W(12) } fn main() { assert!(E::DEFAULT == E::local_fn()); assert!(Option::DEFAULT == Some(23)); assert!(E::NON_DEFAULT == explicit_qpath()); } </ins>

When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per


Question: probe CFG_FLEX             flex probe CFG_BISON            bison probe CFG_PANDOC           pandoc <del> probe CFG_PDFLATEX         pdflatex </del> probe CFG_XELATEX          xelatex <del> probe CFG_LUALATEX         lualatex </del> probe CFG_GDB              gdb probe CFG_LLDB             lldb

Same error, with the last github version.
Also getting this, I'm running the Yosemite GM 1. Not sure if it's related.
I also getting this on MacOs
Still getting this make error, like many others did. Anyone want to fix this?
I have no idea how to fix this, other than just installing xetex or however it's spelled
The configure(or make) did find LuaTeX.
Sadly I don't have time to work on this right now. A simple fix would be to disable pdf generation unless specified in configure, or to require xetex.
I don't think that LaTeX should be a dependency to build a programming language like Rust.
it seems reasonable to have the option to not build PDF docs if you don't want to
I think I'm getting the same error, which is strange because I believe I was able to a couple days ago. In the log, the complaint is that is not found. As suggested above, is included with MacPorts' package and installing that allowed compilation of docs to go through.
will build without building the PDF docs


Question: pub struct FrozenTupleStruct(pub int); #[locked] pub struct LockedTupleStruct(pub int); <ins> #[macro_export] macro_rules! macro_test( () => (deprecated()); ) </ins>

The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc


Question: def read_current_status(current_commit, path): <ins> # type: (str, str) -> typing.Mapping[str, typing.Any] </ins> '''Reads build status of `current_commit` from content of `history/*.tsv` ''' <del> with open(path, 'rU') as f: </del> <ins> with open(path, 'r') as f: </ins> for line in f: (commit, status) = line.split('t', 1) if commit == current_commit:

Updated the toolstate repository at https://rust-lang- currently does not seem to work, see e.g. To "tool failed to build"-issues are being created, either. remarked that the error . Cc


Question: cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

Error happened while working on updating closure capture analysis in rustc which is part of rustctypeck. The highlighted line is what changed between the build that broke and the build before it. <!-- 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. --Version reported in build log and similarly one or two more Complete build log: Build log with : Build directory: (Heads up, this is 29G tar, 39G extracted)
What was the exact build command that caused the ICE? If this is with , then I also see this issue every now and then. Locally built rustc all have the "dev" version string, which means it doesn't have to rebuild everything just because you do , but it also means it cannot detect that the ABI changed, so it might try to load old files with the new rustc and of course that will fail. I am not sure if much can be done about this.
Some potential duplicates: , , ,
I do . This happened to me again last night: The assertion is fired in the not the same line but the same file, I haven't gotten around looking at the query code to see what failed. Only thing I worked on since the last x.py clean (maybe 10-15ish builds in, though I could be wrong) was change closure/generator pretty printing (in rustcmiddle/src/ty/print/pretty), haven't rebased since. Though I can see that rustc builds are themselves are more prone incr compile errors, also didn't think had anything to do with the build process, otherthan maybe some version strings.
Cc I mentioned because one way to avoid this problem might be to embed the git commit in the version string used for rebuild detection -- but that would be rather annoying in many cases.
You can set ignore-git to false in and that'll embed git commit hashes. But I think that must only patch over bugs - it can't be necessary. I doubt it will fully fix this bug. I suspect the problem is that Cargo doesn't delete incremental state on dependency changes - which means that rustc must be prepared, currently, to see incremental state serialized by a different rustc... ideally, handling that in a way that doesn't just throw everything out, but even just not panicking would probably be enough.


Question: cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

See also
The proper way to fix this is to wipe the build cache whenever the stage1 compiler changes. That will make builds a lot slower, but it's better than ICEs and having to wipe the cache anyway. I guess we could add a --keep-stage1-cache flag if you're sure you haven't touched metadata - not sure how useful it would be in practice. said on Zulip:
Wait, I'm confused again. Why does the metadata matter other than the incremental cache? Cargo already invalidates the cache when is modified, which is why libstd gets rebuilt when you modify the compiler. Is there anyone not using that's been hitting this issue?
I found while working on that this is not true: if you use --keep-stage-std 1, cargo will blithely keep the cache for all crates in build/stage1-rustc, without rebuilding. Copying over my comment from
Another possible fix is to make rebuilding after a commit cheap enough that we can include the hash unconditionally. Right now it's used in rustcsession; if we move it to rustcdriver, that would only need to relink the .so and recompile the final rustdoc/clippy/miri crates, not their dependencies. I guess it means we'd have to suggest using keep-stage-std more often :/ but people are doing that pretty frequently already.
Oh, and it has the downside that if you're testing the project on external crates cargo will recompile them after every commit. Maybe that's a good thing?
The only time it won't fully fix the issue is when you're modifying rustc_metadata or similar and don't make a commit between builds. I'm ok with not fixing that case, because anyone working on metadata is much more likely to understand what went happened and how to work around it than random contributors stumbling into this for the first time.
hit this issue this morning with incremental disabled, so it's relevant to all metadata loading, not just incremental.
Thanks for pointing me to the right issue. Following Tried some commits from the past few days Would it be useful to keep going with this approach? Oh, and this is with .
That's helpful, thanks! No need to find more commits, having a reproducer at all is already very useful.
This fundamental issue doesn't just apply to bootstrap, right?


Question: cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

If one uses a locally built toolchain to build some crates, and then updates the toolchain, the same ICEs can arise (because the dependency rlibs will now be in the wrong format). Bootstrap is just where people run into it most often. But a solution inside bootstrap won't fix the fundamental issue. (E.g., it won't fix the Miri version of this problem, which got reported at )
Yes, that's right, any two toolchains that were built from different sources but have the same version string will have this problem (this is why we set a custom description by default in the source tarballs, so they won't reuse metadata from the official toolchain). Removing or defaulting it to would work for miri though, or at least make it so that you have to try a lot harder to run into the bug (e.g. twice with different local changes that haven't been committed).
A more "principled" fix would be to have something like a metadata version number embedded in the files that contributors are responsible for updating when the format changes. But I worry people will forget to update it, the same way people often forget to bump and that causes caching issues:
oh right, and suggested adding incremental to dep-info: but given that this bug is also showing up for metadata, not just incremental, I suspect that's not a complete fix:
Yeah, if we could somehow ensure that such a version number is always correct it would be a proper fix but manual bumping probably won't work. Unless we find a way to at least have CI fail when one forgets to bump...
reported seeing these crashes for , not just for tools and stage 1 rustc. I think he's running into this line being buggy: that shouldn't filter only to build, nearly all the commands read metadata and need the same treatment. Not making a PR because I don't have a test case yet, but if anyone comes up with an MCVE that makes crash, I'd be interested to see if this diff fixes it: also, I wonder if we could fix the original problem with metadata/incremental in stage 1 by applying clearifdirty to rustc too:
reproducer unfortunately gives me a different ICE than the one in the linked issue; it's for stage0, not stage1. So I can't use it to test my diff.


Question: cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

a while ago found that reproduced the issue; if someone could run that both with and without my diff applied to see if it makes a difference that would be helpful; I'm out of time for today.


Question: StorageLive(_3);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15 StorageLive(_4);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:6 _4 = &mut (*_1);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:6 <del> _3 = move _4;                    // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL </del> <ins> StorageLive(_5);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL _5 = &mut (*_4);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL _3 = &mut (*_5);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL StorageDead(_5);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL </ins> _2 = &mut (*_3);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15 StorageDead(_4);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:14: 3:15 _0 = &mut (*_2);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15

Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.


Question: /// Cancel the diagnostic (a structured diagnostic must either be emitted or /// canceled or it will panic when dropped). <del> /// BEWARE: if this DiagnosticBuilder is an error, then creating it will /// bump the error count on the Handler and canceling it won't undo that. /// If you want to decrement the error count you should use `Handler::cancel`. </del> pub fn cancel(&mut self) { self.level = Level::Cancelled; }

Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?


Question: //~^ ERROR generic associated types are unstable } <ins> trait Bar { type Assoc where Self: Sized; //~^ ERROR where clauses on associated types are unstable } </ins> fn main() {}

clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24


Question: let expn_data = prefix_span.ctxt().outer_expn_data(); if expn_data.edition >= Edition::Edition2021 { <del> let mut silence = false; </del> // In Rust 2021, this is a hard error. let sugg = if prefix == "rb" { Some(errors::UnknownPrefixSugg::UseBr(prefix_span))

<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced


Question: <ins> // Copyright 2015 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. #![crate_type="lib"] pub trait Trait { // the issue is sensitive to interning order - so use names // unlikely to appear in libstd. type Issue25467FooT; type Issue25467BarT; } pub type Object = Option<Box<Trait<Issue25467FooT=(),Issue25467BarT=()>>>; </ins>

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


Question: <ins> // Copyright 2015 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. #![crate_type="lib"] pub trait Trait { // the issue is sensitive to interning order - so use names // unlikely to appear in libstd. type Issue25467FooT; type Issue25467BarT; } pub type Object = Option<Box<Trait<Issue25467FooT=(),Issue25467BarT=()>>>; </ins>

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


Question: for autoderefs in range(0, fcx.tcx().sess.recursion_limit.get()) { let resolved_t = structurally_resolved_type(fcx, sp, t); <ins> if ty::type_is_bot(resolved_t) { return (resolved_t, autoderefs, None); } </ins> match should_stop(resolved_t, autoderefs) { Some(x) => return (resolved_t, autoderefs, Some(x)), None => {}

Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.


Question: <ins> // Check that `async fn` inside of an impl with `'_` // in the header compiles correctly. // // Regression test for #63500. // // check-pass // edition:2018 #![feature(async_await)] struct Foo<'a>(&'a u8); impl Foo<'_> { async fn bar() {} } fn main() { } </ins>

The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).


Question: #[inline] #[must_use] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_transmute_copy", issue = "83165")] </del> <ins> #[rustc_const_stable(feature = "const_transmute_copy", since = "CURRENT_RUSTC_VERSION")] </ins> pub const unsafe fn transmute_copy<Src, Dst>(src: &Src) -> Dst { assert!( size_of::<Src>() >= size_of::<Dst>(),

<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for making the function . <!-- Include a short description of the feature. --<!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [ ] Final commenting period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
This got reverted again by , but hopefully we can re-land it soon.
Sorry, I misread, this feature gate is not affected (but some others are).
Any news on this?


Question: #[inline] #[must_use] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_transmute_copy", issue = "83165")] </del> <ins> #[rustc_const_stable(feature = "const_transmute_copy", since = "CURRENT_RUSTC_VERSION")] </ins> pub const unsafe fn transmute_copy<Src, Dst>(src: &Src) -> Dst { assert!( size_of::<Src>() >= size_of::<Dst>(),

I don't see anything holding it back; especially now that transmute itself is const. EDIT: Never mind, I just saw
Since is const-stable nowadays, I think this can be stabilized as well. Feel free to open a PR. :) Cc
I didn't do this before, I am reading the docs for how to do this, and there's an rfcbot final commenting period thing. Should this be done? If yes, how? I probably don't have the rights to do it.
You just need to prepare a PR. I can help get the FCP process started in the PR.


Question: /// assert!(ascii.is_ascii()); /// assert!(!non_ascii.is_ascii()); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> #[inline] pub fn is_ascii(&self) -> bool { self.inner.is_ascii()

<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] - Stabilized traits necessary to obtain [x] - Added ASCII methods on [x] Final commenting period (FCP) [x] - Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Just needed to manipulate paths on windows -- I need to lower case driver letter, -.
Currently, SQLx contains The UTF-8 check that is included in there, while not a problem in practice, seems pointless. Changing to lands me here because of the .


Question: /// assert!(ascii.is_ascii()); /// assert!(!non_ascii.is_ascii()); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> #[inline] pub fn is_ascii(&self) -> bool { self.inner.is_ascii()

Also, if somebody did a similar thing with instead of , the version could drop that and would then be a bit less noisy.
is a stabilization PR. Since lib team wants to do fcp in the tracking issue. could you start one ?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] Concerns: resolved by Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Slight question about -- normally when dealing with AsRef args, they come in without an explicit reference in the signature (), except when necessary to support a lifetime in the return value (). Currently is declared as: Is this supposed to be instead? concern eqignoreasciicase &S
I think it should be. I'm not sure why I wrote it like I did originally, but this makes more sense to me. I can make that PR if needed. Or can it be done in the stabilization PR? Not sure what the process is from here.
resolve eqignoreascii_case &S reviewed Fixed in .
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
you can tick the FCP box, as the FCP is complete.


Question: let p = Command::new("cmd").args(&["/C", "exit 0"]).env_clear().spawn(); assert!(p.is_ok()); } <ins> // See issue #91991 #[test] #[cfg(windows)] fn run_bat_script() { let tempdir = crate::sys_common::io::test::tmpdir(); let script_path = tempdir.join("hello.cmd"); crate::fs::write(&script_path, "@echo Hello, %~1!").unwrap(); let output = Command::new(&script_path) .arg("fellow Rustaceans") .stdout(crate::process::Stdio::piped()) .spawn() .unwrap() .wait_with_output() .unwrap(); assert!(output.status.success()); assert_eq!(String::from_utf8_lossy(&output.stdout).trim(), "Hello, fellow Rustaceans!"); } </ins>

I tried this code: I expected to see this happen: Instead, this happened: This is caused by different quote handling. The first (correct) command line for the spawned process (as observed by ) is: The broken one is: The command for must be in additional set of quotes, as the first and last one are stripped. It works when there are no spaces in the arguments due to the exception rule, see Stable. It worked up until nightly-2021-11-20 nightly-2021-11-21 modify labels: +regression-from-stable-to-nightly -regression-untriaged
This is caused by Rust now handling finding the exe to run itself (for security reasons). The fix here would be. as you say, to detect or extensions and add the extra quotes. The underlying function call here is . As the documentation says, this can only be used to run files. However, an undocumented feature of is that it will do this for us if given a or file. Previously we used to leave the argument blank and let it guess the right application from the argument. So apparently it would fill in for the application name and add plus the extra quotes to . But now that we do fill in the ourselves, it will still change to and add to but evidentially doesn't add the extra quotes. Thus we need to do this ourselves.
That seems reasonable; could you or someone on the Windows team submit a PR adding the requisite quoting (since quoting is hard to get right)?
Oops, sorry! I had a PR lined up but forgot to submit.


Question: if ast_util::is_local(self.item.def_id) { let mut path = Vec::new(); clean_srcpath(&cx.src_root, Path::new(&self.item.source.filename), <del> |component| { </del> <ins> true, |component| { </ins> path.push(component.to_string()); }); let href = if self.item.source.loline == self.item.source.hiline {

When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<


Question: # tarball for a stable release you'll likely see `1.x.0-$date` where `1.x.0` was # released on `$date` <del> rustc: beta-2017-03-21 </del> <ins> rustc: beta-2017-04-05 </ins>

While bootstrapping on Fedora 25 armv7l, I'm hitting a SIGILL when some beta-compiled programs are actually executed. This is with a purely default , no external LLVM or anything. On beta (exactly ), I get a little ways into stage1, and then build scripts SIGILL, apparently from double-panics. I reckon that the stable stage0 builds a stage1 compiler that's fine, then that stage1 starts building things that don't even need to execute until we get to a build script. Then: So I also tried the master branch (exactly ), and that fails as soon as it executes at the start of stage1. Here it seems that the downloaded beta stage0 compiler builds all of its stuff fine, which presumably includes executing some builds scripts like above. But the stage1 it creates seems to be bad: I traced through with gdb, and it's not actually crashing, rather the that it execs into. Here's the backtrace: That looks like a triple panic! The actual SIGILL is delivered for a instruction:
(side note: on the beta branch I have also applied , or else you have to configure with an explicit to get armv7.)
I tried to build a debug nightly, but it can't link to in stage0's librustcconstmath:
Looking at , it seems SIGILL is expected because of the . The questions are then, why did it panic in the first place and why did the default hook panic?
is where the default hook is panicking.
Yes, I agree the SIGILL is just a symptom of the nested panics, not something to fix in itself. While I couldn't get a debug build, I got a release build with debuginfo. Here's a better backtrace from running : So the first panic comes from the failed at frame called from . The line right before got a shared -- maybe something isn't marking this released properly? Then the nested panics come from trying to read this same broken , with frames and also trying to .
Looks like you are using an LLVM without the fix in . That will blatantly miscompile rustc and lead to severe problems.
While it does sound the same, unfortunately no, this is with the rust-bundled LLVM, including your fix.


Question: # tarball for a stable release you'll likely see `1.x.0-$date` where `1.x.0` was # released on `$date` <del> rustc: beta-2017-03-21 </del> <ins> rustc: beta-2017-04-05 </ins>

:/
That said, there must be something local going wrong, as the official (cross-build) armv7 compiler seems to work fine, at least with the same simple reproducer, e.g. . I'm going to try a fresh build on a fresh system with absolutely no local LLVM present...
So -- that worked, both beta and nightly. I'll make sure to update our distro LLVM patches. What tripped me up on nightly was that stage0 is still 1.17.0-beta.2, which doesn't have the LLVM fix. I bumped that to beta.3, and then it worked. This doesn't affect the official nightly builds because only the host compiler goes through stages, and AIUI the cross-compiled targets only use the host stage2. But doing a native arm compile, the bugged stage0 gave me an unusable stage1. On beta, I don't know what happened before. I think perhaps somewhere when I was jumping between local and rust-llvm and testing different branches, I must have gotten a build of the still-broken rust-llvm, with a timestamp such that rustbuild didn't think it needed rebuilding on the fixed sources. I still have that build directory tarballed here, so I may poke at it when I get a free moment.
So we should update 1.18's stage0?
OK, see to bump stage0.


Question: <del> Subproject commit bf88026f11f2cc7bb9fefdfe1dbcab642f110afa </del> <ins> Subproject commit f37425e33c864c697af06df66e7473444605c149 </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.


Question: <del> Subproject commit bf88026f11f2cc7bb9fefdfe1dbcab642f110afa </del> <ins> Subproject commit f37425e33c864c697af06df66e7473444605c149 </ins>

One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on


Question: without modifying the original"] #[inline] #[track_caller] <del> #[rustc_inherit_overflow_checks] #[allow(arithmetic_overflow)] </del> pub const fn ilog(self, base: Self) -> u32 { <del> match self.checked_ilog(base) { Some(n) => n, None => { // In debug builds, trigger a panic on None. // This should optimize completely out in release builds. let _ = Self::MAX + 1; 0 }, } </del> <ins> assert!(base >= 2, "base of integer logarithm must be at least 2"); self.checked_ilog(base).expect("argument of integer logarithm must be positive") </ins> } /// Returns the base 2 logarithm of the number, rounded down. /// /// # Panics /// <del> /// When the number is zero it panics in debug mode and /// the return value is 0 in release mode. </del> <ins> /// This function will panic if `self` is zero. </ins> /// /// # Examples ///

Filing since it's in pFCP over at , and I don't think we can reasonably change it after stabilization (especially since it's documented). Currently, in release mode evaluates to . (And same for the other bases.) It's not obvious to me that that's necessarily the best option. For example, the implementation is slightly nicer on CPUs from the past or so (and I think would be just as nice on older ones ), but gives <subas u32</subin the wrapping case. It also might be nice to have the wrapping case give something clearly different from any of the successful cases, rather than having and give the same thing. For example returns in release mode, which isn't a power of two (according to ), so it's distinguishable from all the non-wrapping cases. This only affects // on . (The checked versions don't have an issue, nor do the ones on .)
I couldn't find any previous discussion of what the exact wrapping value ought to be, just that there ought to be one, as opposed to a . There was this note: For which I think the implementation I mention above is a counter-example, albeit only for the base-2 case. Also, currently in release mode is essentially , so we can pick any value we want to return for those cases. FWIW, the implementation in gives as the result for .
In Rust we try to do the right thing. Not even Python gives -1. Let's avoid in-band error values in Rust.
What's your proposal for what the "right" thing is, then? That panic in release too? Arguably the most-correct value is −∞ (like ), but that doesn't fit in any of our integer types. So would make sense, but release mode for the other un-prefixed things is wrapping, not saturating.
Python has some functions that return in-band values: "xy".find("y") 1 "xy".find("z") -1 From Rust I expect something better. In Rust if a function isn't naturally total and you can't restrict its input, then I expect it to return Option (or Result), or when that's isn't ergonomic enough, a panic (in release too). Returning -1 is dangerous as that Python find function, returning 0 is not math.


Question: without modifying the original"] #[inline] #[track_caller] <del> #[rustc_inherit_overflow_checks] #[allow(arithmetic_overflow)] </del> pub const fn ilog(self, base: Self) -> u32 { <del> match self.checked_ilog(base) { Some(n) => n, None => { // In debug builds, trigger a panic on None. // This should optimize completely out in release builds. let _ = Self::MAX + 1; 0 }, } </del> <ins> assert!(base >= 2, "base of integer logarithm must be at least 2"); self.checked_ilog(base).expect("argument of integer logarithm must be positive") </ins> } /// Returns the base 2 logarithm of the number, rounded down. /// /// # Panics /// <del> /// When the number is zero it panics in debug mode and /// the return value is 0 in release mode. </del> <ins> /// This function will panic if `self` is zero. </ins> /// /// # Examples ///

I think returning (wrapped if necessary) is a clear distinguish between normal and error result. Returning an is not ideal currently because it will makes the function practically unusable in const context (before const unwrap is stabilized) If getting closest to the "correct" math answer, how about choosing ? However it seems weird and still seems better to me
Perhaps in other languages. Rust is known for being better than that. I have chosen to use Rust because it's a bit better than Python (see above). Let's return Option and and wait for const unwrap to be stabilized before making ilog const, then.
That's what does already. Is your proposal, then, that the version of just shouldn't exist on ? How do you square that with precedent of other things -- like or -- that have the version return , but the un-prefixed one wrap in release mode?
what about treating it like division by zero and just panicking?
I'd be fine with -1. The point of these methods is to get fast code (otherwise many won't use them and will prefer to do to keep the code branchless and avoid the ugly ) and a defined value outside of the usual input range. (from above) is a good example. If you want stricter guarantees than that, you can use .
A minor point: being 0 is actually a reasonable choice - even though 0 is not a power of two, it is congruent to the correct power of two modulo 2^32 (which is 2^32 itself), so exactly what is expected in wrapping arithmetic. But unfortunately there's no "−∞ mod 2^32" that could be used for .
Modular arithmetic is confusing in the context of logarithm, if you want to return the discrete logarithm of 0 in the release mode, then there are a lot of candidates, because (in case of ) therefore in the sense of modular arithmetic, could be any multiple of . If you really want to achieve something close to , then I guess the best value is as I mentioned above. (Interestingly though, = , which is a multiple of 8, 16, 32, 64, 128)
That's certainly a possibility. suggested not doing that back in the original PR, though:
Doesn't implicitly include a check for zero in the code generated?


Question: without modifying the original"] #[inline] #[track_caller] <del> #[rustc_inherit_overflow_checks] #[allow(arithmetic_overflow)] </del> pub const fn ilog(self, base: Self) -> u32 { <del> match self.checked_ilog(base) { Some(n) => n, None => { // In debug builds, trigger a panic on None. // This should optimize completely out in release builds. let _ = Self::MAX + 1; 0 }, } </del> <ins> assert!(base >= 2, "base of integer logarithm must be at least 2"); self.checked_ilog(base).expect("argument of integer logarithm must be positive") </ins> } /// Returns the base 2 logarithm of the number, rounded down. /// /// # Panics /// <del> /// When the number is zero it panics in debug mode and /// the return value is 0 in release mode. </del> <ins> /// This function will panic if `self` is zero. </ins> /// /// # Examples ///

]
Also, since the methods are implemented for signed integers as well, another issue would be the log of negative values. For example for floating-point, would return −∞, but would return NaN. So if would return some value for −∞, would panic anyway, or return some value?
I don't think it makes sense to do anything other than panic in the case of negative values, which in turn is probably an argument for panicking on zero as well. I guess one could argue that "wrapping" could be interpreted as wrapping the preimage to fit in the function's domain (rather than just wrapping the image to fit in the range) but IMO that would be entirely unintuitive and unhelpful as well. After thinking about it a bit, it seems to me that simply cannot have a meaningful variant, because semantics (as reasonably interpreted) cannot answer the question "what should the result be for values for which the original function is undefined?" There are no elements in 's domain for which the function underflows or overflows.
That's only the case on old chips. As I linked in the OP (), that happens in the instruction generation very-last-phase of LLVM on old chips, and on newer chips it knows to emit a different instruction instead of the branching code: The good news is that it looks like newer LLVM has gotten smarter here. It used to be that, because of how the intrinsic gets translated, it would emit obviously-redundant assembly on old chips in some code patterns, as you could see in Rust 1.16:
is supposed to find the largest so that . Since computers use wrapping arithmetic, the equation is better put as . The largest satisfying this equation in the case is (aka ). So if we consider a wrapping to be the inverse of , makes perfect sense (and is very efficient on modern CPUs, as others have pointed out). I would also advocate for to be as a method which always has this behaviour. [Edit: it already behaves that way]
Note that's already how works . It's just that it wraps to in release right now -- this issue doesn't propose removing the panic in debug behaviour, just to figure out what the best value for release would be.