Question: = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced) = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers) <ins> Future breakage diagnostic: error: reference to packed field is unaligned --> $DIR/unaligned_references.rs:90:20 | LL |         let _ref = &m1.1.a; |                    ^^^^^^^ | note: the lint level is defined here --> $DIR/unaligned_references.rs:1:9 | LL | #![deny(unaligned_references)] |         ^^^^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523> = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced) = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers) Future breakage diagnostic: error: reference to packed field is unaligned --> $DIR/unaligned_references.rs:100:20 | LL |         let _ref = &m2.1.a; |                    ^^^^^^^ | note: the lint level is defined here --> $DIR/unaligned_references.rs:1:9 | LL | #![deny(unaligned_references)] |         ^^^^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523> = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced) = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers) </ins>

And this can't take place inside the callee because the callee receives a , and if that reference is unaligned then UB has already occurred and there's nothing the callee can do to fix things anymore
takes a raw pointer, so it could very well be the place where the packed struct alignment trouble is handled. And IMO it'd be a much more natural place than doing this by transforming caller MIR.
I don't understand the suggestion. The example above never calls for a packed struct. The offending drop in the MIR in the example above is . The type of that place is - but if were to be responsible for moving, then we would need to emit a move in literally every drop shim for a non-trivial alignment type.
Oh I see, I didn't quite read the example correctly. The problematic drop is the one that happens on field assignment, and we know it's a packed field because of the path we are accessing it with. EDIT: no wait this makes no sense. Now I am confused by your comment.
No what I just said makes no sense. What happens is that this is a partial drop -- one field has been moved out () and then the logic for dropping the remaining fields seems to be wrong. So is relevant because it changed . And it looks like somehow the change is wrong; here is also despite the reference being unaligned.
should fix this.


Question: // + span: $DIR/nrvo-simple.rs:3:20: 3:21 // + literal: Const { ty: u8, val: Value(Scalar(0x00)) } StorageLive(_3);                 // scope 1 at $DIR/nrvo-simple.rs:4:5: 4:19 <ins> StorageLive(_5);                 // scope 1 at $DIR/nrvo-simple.rs:4:10: 4:18 StorageLive(_6);                 // scope 1 at $DIR/nrvo-simple.rs:4:10: 4:18 </ins> -         _6 = &mut _2;                    // scope 1 at $DIR/nrvo-simple.rs:4:10: 4:18 +         _6 = &mut _0;                    // scope 1 at $DIR/nrvo-simple.rs:4:10: 4:18 <del> _3 = move _1(move _6) -> bb1;    // scope 1 at $DIR/nrvo-simple.rs:4:5: 4:19 </del> <ins> _5 = &mut (*_6);                 // scope 1 at $DIR/nrvo-simple.rs:4:10: 4:18 _3 = move _1(move _5) -> bb1;    // scope 1 at $DIR/nrvo-simple.rs:4:5: 4:19 </ins> } bb1: { <ins> StorageDead(_5);                 // scope 1 at $DIR/nrvo-simple.rs:4:18: 4:19 StorageDead(_6);                 // scope 1 at $DIR/nrvo-simple.rs:4:19: 4:20 </ins> StorageDead(_3);                 // scope 1 at $DIR/nrvo-simple.rs:4:19: 4:20 -         _0 = _2;                         // scope 1 at $DIR/nrvo-simple.rs:5:5: 5:8 -         StorageDead(_2);                 // scope 0 at $DIR/nrvo-simple.rs:6:1: 6:2

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: this.visit_ty(&ty); } } <del> GenericParamKind::Const { ref ty, .. } => { </del> <ins> GenericParamKind::Const { ref ty, default } => { </ins> let was_in_const_generic = this.is_in_const_generic; this.is_in_const_generic = true; walk_list!(this, visit_param_bound, param.bounds); this.visit_ty(&ty); <ins> if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } </ins> this.is_in_const_generic = was_in_const_generic; } }

Const generic defaults are being stabilized, <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ?


Question: this.visit_ty(&ty); } } <del> GenericParamKind::Const { ref ty, .. } => { </del> <ins> GenericParamKind::Const { ref ty, default } => { </ins> let was_in_const_generic = this.is_in_const_generic; this.is_in_const_generic = true; walk_list!(this, visit_param_bound, param.bounds); this.visit_ty(&ty); <ins> if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } </ins> this.is_in_const_generic = was_in_const_generic; } }

Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta


Question: } else { cmd = Command::new(&output_file); if doctest.is_multiple_tests { <del> cmd.arg("*doctest-bin-path"); cmd.arg(&output_file); </del> <ins> cmd.env("RUSTDOC_DOCTEST_BIN_PATH", &output_file); </ins> } } if let Some(run_directory) = &rustdoc_options.test_run_directory {

The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.


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

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


Question: <ins> fn foo<T: impl Trait>() {} //~^ ERROR expected trait bound, found `impl Trait` type fn main() {} </ins>

When writing the current error is "expected one of these tokens", without any attempt to recover the parse. It should instead be closer to: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
What do you expect the suggestion from this code? here is a valid identifier, "expected one of these tokens" comes when the second identifier comes.
I think this case should remain as is. in particular is a shame because it is a valid type for the parser, but not a valid trait, and newcomers might not yet have a mental model for the distinction. I would say, when parsing a trait, if it can't be parsed, then try to parse a type in a snapshot (like we do in other parts of the parser), and if successful, emit a targeted error (trait expected but found type).
claim


Question: <ins> mod foo { pub struct B(()); } mod bar { use foo::B; fn foo() { B(()); //~ ERROR expected function, found struct `B` [E0423] } } mod baz { fn foo() { B(()); //~ ERROR cannot find function `B` in this scope [E0425] } } fn main() {} </ins>

For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.


Question: prepare("rust-mingw"); } <del> builder.install(&xform(&etc.join("exe/rust.iss")), &exe, 0o644); builder.install(&etc.join("exe/modpath.iss"), &exe, 0o644); builder.install(&etc.join("exe/upgrade.iss"), &exe, 0o644); </del> builder.install(&etc.join("gfx/rust-logo.ico"), &exe, 0o644); <del> builder.create(&exe.join("LICENSE.txt"), &license); // Generate exe installer builder.info("building `exe` installer with `iscc`"); let mut cmd = Command::new("iscc"); cmd.arg("rust.iss").arg("/Q").current_dir(&exe); if target.contains("windows-gnu") { cmd.arg("/dMINGW"); } add_env(builder, &mut cmd, target); let time = timeit(builder); builder.run(&mut cmd); drop(time); builder.install( &exe.join(format!("{}-{}.exe", pkgname(builder, "rust"), target)), &distdir(builder), 0o755, ); </del> // Generate msi installer let wix = PathBuf::from(env::var_os("WIX").unwrap());

The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them.


Question: prepare("rust-mingw"); } <del> builder.install(&xform(&etc.join("exe/rust.iss")), &exe, 0o644); builder.install(&etc.join("exe/modpath.iss"), &exe, 0o644); builder.install(&etc.join("exe/upgrade.iss"), &exe, 0o644); </del> builder.install(&etc.join("gfx/rust-logo.ico"), &exe, 0o644); <del> builder.create(&exe.join("LICENSE.txt"), &license); // Generate exe installer builder.info("building `exe` installer with `iscc`"); let mut cmd = Command::new("iscc"); cmd.arg("rust.iss").arg("/Q").current_dir(&exe); if target.contains("windows-gnu") { cmd.arg("/dMINGW"); } add_env(builder, &mut cmd, target); let time = timeit(builder); builder.run(&mut cmd); drop(time); builder.install( &exe.join(format!("{}-{}.exe", pkgname(builder, "rust"), target)), &distdir(builder), 0o755, ); </del> // Generate msi installer let wix = PathBuf::from(env::var_os("WIX").unwrap());

I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.


Question: <ins> Version 1.54.0 (2021-07-29) ============================ Language ----------------------- - [You can now use macros for values in built-in attribute macros.][83366] While a seemingly minor addition on its own, this enables a lot of powerful functionality when combined correctly. Most notably you can now include external documentation in your crate by writing the following. ```rust #![doc = include_str!("README.md")] ``` You can also use this to include auto-generated modules: ```rust #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod generated; ``` - [You can now cast between unsized slice types (and types which contain unsized slices) in `const fn`.][85078] - [You can now use multiple generic lifetimes with `impl Trait` where the lifetimes don't explicitly outlive another.][84701] In code this means that you can now have `impl Trait<'a, 'b>` where as before you could only have `impl Trait<'a, 'b> where 'b: 'a`. Compiler ----------------------- - [Rustc will now search for custom JSON targets in `/lib/rustlib/<target-triple>/target.json` where `/` is the "sysroot" directory.][83800] You can find your sysroot directory by running `rustc --print sysroot`. - [Added `wasm` as a `target_family` for WebAssembly platforms.][84072] - [You can now use `#[target_feature]` on safe functions when targeting WebAssembly platforms.][84988] - [Improved debugger output for enums on Windows MSVC platforms.][85292] - [Added tier 3* support for `bpfel-unknown-none` and `bpfeb-unknown-none`.][79608] * Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries ----------------------- - [`panic::panic_any` will now `#[track_caller]`.][85745] - [Added `OutOfMemory` as a variant of `io::ErrorKind`.][84744] - [ `proc_macro::Literal` now implements `FromStr`.][84717] - [The implementations of vendor intrinsics in core::arch have been significantly refactored.][83278] The main user-visible changes are a 50% reduction in the size of libcore.rlib and stricter validation of constant operands passed to intrinsics. The latter is technically a breaking change, but allows Rust to more closely match the C vendor intrinsics API. Stabilized APIs --------------- - [`BTreeMap::into_keys`] - [`BTreeMap::into_values`] - [`HashMap::into_keys`] - [`HashMap::into_values`] - [`arch::wasm32`] - [`VecDeque::binary_search`] - [`VecDeque::binary_search_by`] - [`VecDeque::binary_search_by_key`] - [`VecDeque::partition_point`] Cargo ----------------------- - [Added the `--prune <spec>` option to `cargo-tree` to remove a package from the dependency graph.][cargo/9520] - [Added the `--depth` option to `cargo-tree` to print only to a certain depth in the tree ][cargo/9499] - [Added the `no-proc-macro` value to `cargo-tree --edges` to hide procedural macro dependencies.][cargo/9488] - [A new environment variable named `CARGO_TARGET_TMPDIR` is available.][cargo/9375] This variable points to a directory that integration tests and benches can use as a "scratchpad" for testing filesystem operations. [79608]: https://github.com/rust-lang/rust/pull/79608 [84988]: https://github.com/rust-lang/rust/pull/84988 [84701]: https://github.com/rust-lang/rust/pull/84701 [84072]: https://github.com/rust-lang/rust/pull/84072 [85745]: https://github.com/rust-lang/rust/pull/85745 [84744]: https://github.com/rust-lang/rust/pull/84744 [85078]: https://github.com/rust-lang/rust/pull/85078 [84717]: https://github.com/rust-lang/rust/pull/84717 [83800]: https://github.com/rust-lang/rust/pull/83800 [83366]: https://github.com/rust-lang/rust/pull/83366 [83278]: https://github.com/rust-lang/rust/pull/83278 [85292]: https://github.com/rust-lang/rust/pull/85292 [cargo/9520]: https://github.com/rust-lang/cargo/pull/9520 [cargo/9499]: https://github.com/rust-lang/cargo/pull/9499 [cargo/9488]: https://github.com/rust-lang/cargo/pull/9488 [cargo/9375]: https://github.com/rust-lang/cargo/pull/9375 [`BTreeMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_keys [`BTreeMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_values [`HashMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_keys [`HashMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_values [`arch::wasm32`]: https://doc.rust-lang.org/core/arch/wasm32/index.html [`VecDeque::binary_search`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search [`VecDeque::binary_search_by`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by [`VecDeque::binary_search_by_key`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by_key [`VecDeque::partition_point`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.partition_point </ins> Version 1.53.0 (2021-06-17) ============================

As noted in which tracks the diagnostic issue, the standard library previously accepted code (with differing behavior) on a number of intrinsics with "intended to be const" arguments. Since , though, this code is rejected at compile-time. For example, this compiles on stable but not 1.54 (nightly as of this writing). I think at minimum we need to identify the set of code that changed behaviors and document that in release notes.
cc -- on the point about documenting this change in behavior in the release notes, would you be up for either identifying the set of intrinsics which changed behavior or documenting how to do so?
Looking back at the crater run, we only ran it in mode, which doesn't perform monomorphization. This is the reason why this wasn't caught earlier. The full crater run for beta is currently running, so we should be able to get a clearer picture of the breakage once it is done. Documenting this is difficult: the new behavior affects all intrinsics which use const arguments. A quick grep of stdarch shows 1741 intrinsics, of which about ~150 are stable.
This is in 1.54, not 1.53, so the currently running beta run won't catch anything, right? It may make sense to run a crater on the PR itself, though. It is worrying that so many intrinsics are affected towards a compile-error, vs. e.g. having a warning - perhaps deny-by-default - like clippy's on the atomic Ordering params...
run mode=build-only end= start= name=issue-
:okhand: Experiment created and queued. :mag: You can check out and . :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
The mechanism used to validate the immediates using const generics is: offering the validation feature: a post-monomorphization error while evaluating a forcing the evaluation of the const for the const generic parameters of a given intrinsic: e.g. the above is as and the body of the intrinsic will start with a static assertion ensuring is indeed a 4-bit value. Note that I've linked to the more common macros, but this mechanism is applied throughout including arch-specific intrinsics and validations: e.g. , or .


Question: <ins> Version 1.54.0 (2021-07-29) ============================ Language ----------------------- - [You can now use macros for values in built-in attribute macros.][83366] While a seemingly minor addition on its own, this enables a lot of powerful functionality when combined correctly. Most notably you can now include external documentation in your crate by writing the following. ```rust #![doc = include_str!("README.md")] ``` You can also use this to include auto-generated modules: ```rust #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod generated; ``` - [You can now cast between unsized slice types (and types which contain unsized slices) in `const fn`.][85078] - [You can now use multiple generic lifetimes with `impl Trait` where the lifetimes don't explicitly outlive another.][84701] In code this means that you can now have `impl Trait<'a, 'b>` where as before you could only have `impl Trait<'a, 'b> where 'b: 'a`. Compiler ----------------------- - [Rustc will now search for custom JSON targets in `/lib/rustlib/<target-triple>/target.json` where `/` is the "sysroot" directory.][83800] You can find your sysroot directory by running `rustc --print sysroot`. - [Added `wasm` as a `target_family` for WebAssembly platforms.][84072] - [You can now use `#[target_feature]` on safe functions when targeting WebAssembly platforms.][84988] - [Improved debugger output for enums on Windows MSVC platforms.][85292] - [Added tier 3* support for `bpfel-unknown-none` and `bpfeb-unknown-none`.][79608] * Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries ----------------------- - [`panic::panic_any` will now `#[track_caller]`.][85745] - [Added `OutOfMemory` as a variant of `io::ErrorKind`.][84744] - [ `proc_macro::Literal` now implements `FromStr`.][84717] - [The implementations of vendor intrinsics in core::arch have been significantly refactored.][83278] The main user-visible changes are a 50% reduction in the size of libcore.rlib and stricter validation of constant operands passed to intrinsics. The latter is technically a breaking change, but allows Rust to more closely match the C vendor intrinsics API. Stabilized APIs --------------- - [`BTreeMap::into_keys`] - [`BTreeMap::into_values`] - [`HashMap::into_keys`] - [`HashMap::into_values`] - [`arch::wasm32`] - [`VecDeque::binary_search`] - [`VecDeque::binary_search_by`] - [`VecDeque::binary_search_by_key`] - [`VecDeque::partition_point`] Cargo ----------------------- - [Added the `--prune <spec>` option to `cargo-tree` to remove a package from the dependency graph.][cargo/9520] - [Added the `--depth` option to `cargo-tree` to print only to a certain depth in the tree ][cargo/9499] - [Added the `no-proc-macro` value to `cargo-tree --edges` to hide procedural macro dependencies.][cargo/9488] - [A new environment variable named `CARGO_TARGET_TMPDIR` is available.][cargo/9375] This variable points to a directory that integration tests and benches can use as a "scratchpad" for testing filesystem operations. [79608]: https://github.com/rust-lang/rust/pull/79608 [84988]: https://github.com/rust-lang/rust/pull/84988 [84701]: https://github.com/rust-lang/rust/pull/84701 [84072]: https://github.com/rust-lang/rust/pull/84072 [85745]: https://github.com/rust-lang/rust/pull/85745 [84744]: https://github.com/rust-lang/rust/pull/84744 [85078]: https://github.com/rust-lang/rust/pull/85078 [84717]: https://github.com/rust-lang/rust/pull/84717 [83800]: https://github.com/rust-lang/rust/pull/83800 [83366]: https://github.com/rust-lang/rust/pull/83366 [83278]: https://github.com/rust-lang/rust/pull/83278 [85292]: https://github.com/rust-lang/rust/pull/85292 [cargo/9520]: https://github.com/rust-lang/cargo/pull/9520 [cargo/9499]: https://github.com/rust-lang/cargo/pull/9499 [cargo/9488]: https://github.com/rust-lang/cargo/pull/9488 [cargo/9375]: https://github.com/rust-lang/cargo/pull/9375 [`BTreeMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_keys [`BTreeMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_values [`HashMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_keys [`HashMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_values [`arch::wasm32`]: https://doc.rust-lang.org/core/arch/wasm32/index.html [`VecDeque::binary_search`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search [`VecDeque::binary_search_by`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by [`VecDeque::binary_search_by_key`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by_key [`VecDeque::partition_point`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.partition_point </ins> Version 1.53.0 (2021-06-17) ============================

Any intrinsic using these macros can cause an error like in the OP with an argument that doesn't pass the checks, but this set of functions should be equivalent to: all the intrinsics which have been ported to . This means this mechanism is very well centralized and could be deactivated depending on the new crater run results, however that'd mean that we would return to the current situation of, depending on the intrinsics, having assertions or crashes in LLVM instead.
And the move to 'proper' const generics and the new validation are coupled because we would otherwise have undefined behavior (or be unable to codegen? -- what would happen)? Or can we decouple them?
We get LLVM assertion failures if invalid values reach codegen. I'm not sure if decoupling is even possible. For example, these don't work in debug builds:
It might be possible to do something involving specialization on const arguments... that seems rather fragile though. An alternative might be to change the LLVM IR generated by rustc, but it seems like currently rustc has no idea about the structure of these LLVM intrinsics so that probably won't be easy either. How is it then possible that the example in the OP here compiles and runs on stable?
Previously stdarch had massive statements to convert the value to a constant argument for the intrinsic.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:rotatinglight: Experiment has encountered an error: command failed: exit code: 1 :hammerandwrench: If the error is fixed use the command. :sos: Can someone from the infra team check in on this? :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:rotatinglight: Experiment has encountered an error: command failed: exit code: 1 :hammerandwrench: If the error is fixed use the command. :sos: Can someone from the infra team check in on this? :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.


Question: <ins> Version 1.54.0 (2021-07-29) ============================ Language ----------------------- - [You can now use macros for values in built-in attribute macros.][83366] While a seemingly minor addition on its own, this enables a lot of powerful functionality when combined correctly. Most notably you can now include external documentation in your crate by writing the following. ```rust #![doc = include_str!("README.md")] ``` You can also use this to include auto-generated modules: ```rust #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod generated; ``` - [You can now cast between unsized slice types (and types which contain unsized slices) in `const fn`.][85078] - [You can now use multiple generic lifetimes with `impl Trait` where the lifetimes don't explicitly outlive another.][84701] In code this means that you can now have `impl Trait<'a, 'b>` where as before you could only have `impl Trait<'a, 'b> where 'b: 'a`. Compiler ----------------------- - [Rustc will now search for custom JSON targets in `/lib/rustlib/<target-triple>/target.json` where `/` is the "sysroot" directory.][83800] You can find your sysroot directory by running `rustc --print sysroot`. - [Added `wasm` as a `target_family` for WebAssembly platforms.][84072] - [You can now use `#[target_feature]` on safe functions when targeting WebAssembly platforms.][84988] - [Improved debugger output for enums on Windows MSVC platforms.][85292] - [Added tier 3* support for `bpfel-unknown-none` and `bpfeb-unknown-none`.][79608] * Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries ----------------------- - [`panic::panic_any` will now `#[track_caller]`.][85745] - [Added `OutOfMemory` as a variant of `io::ErrorKind`.][84744] - [ `proc_macro::Literal` now implements `FromStr`.][84717] - [The implementations of vendor intrinsics in core::arch have been significantly refactored.][83278] The main user-visible changes are a 50% reduction in the size of libcore.rlib and stricter validation of constant operands passed to intrinsics. The latter is technically a breaking change, but allows Rust to more closely match the C vendor intrinsics API. Stabilized APIs --------------- - [`BTreeMap::into_keys`] - [`BTreeMap::into_values`] - [`HashMap::into_keys`] - [`HashMap::into_values`] - [`arch::wasm32`] - [`VecDeque::binary_search`] - [`VecDeque::binary_search_by`] - [`VecDeque::binary_search_by_key`] - [`VecDeque::partition_point`] Cargo ----------------------- - [Added the `--prune <spec>` option to `cargo-tree` to remove a package from the dependency graph.][cargo/9520] - [Added the `--depth` option to `cargo-tree` to print only to a certain depth in the tree ][cargo/9499] - [Added the `no-proc-macro` value to `cargo-tree --edges` to hide procedural macro dependencies.][cargo/9488] - [A new environment variable named `CARGO_TARGET_TMPDIR` is available.][cargo/9375] This variable points to a directory that integration tests and benches can use as a "scratchpad" for testing filesystem operations. [79608]: https://github.com/rust-lang/rust/pull/79608 [84988]: https://github.com/rust-lang/rust/pull/84988 [84701]: https://github.com/rust-lang/rust/pull/84701 [84072]: https://github.com/rust-lang/rust/pull/84072 [85745]: https://github.com/rust-lang/rust/pull/85745 [84744]: https://github.com/rust-lang/rust/pull/84744 [85078]: https://github.com/rust-lang/rust/pull/85078 [84717]: https://github.com/rust-lang/rust/pull/84717 [83800]: https://github.com/rust-lang/rust/pull/83800 [83366]: https://github.com/rust-lang/rust/pull/83366 [83278]: https://github.com/rust-lang/rust/pull/83278 [85292]: https://github.com/rust-lang/rust/pull/85292 [cargo/9520]: https://github.com/rust-lang/cargo/pull/9520 [cargo/9499]: https://github.com/rust-lang/cargo/pull/9499 [cargo/9488]: https://github.com/rust-lang/cargo/pull/9488 [cargo/9375]: https://github.com/rust-lang/cargo/pull/9375 [`BTreeMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_keys [`BTreeMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_values [`HashMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_keys [`HashMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_values [`arch::wasm32`]: https://doc.rust-lang.org/core/arch/wasm32/index.html [`VecDeque::binary_search`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search [`VecDeque::binary_search_by`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by [`VecDeque::binary_search_by_key`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by_key [`VecDeque::partition_point`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.partition_point </ins> Version 1.53.0 (2021-06-17) ============================

edit end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master# name=issue-
:rotatinglight: Error: failed to parse the command :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:rotatinglight: Error: it's only possible to edit queued experiments :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:memo: Configuration of the experiment changed. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:tada: Experiment is completed! :barchart: 56 regressed and 14 fixed ( total) :newspaper: . :warning: If you notice any spurious failure ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
All of the new failures that weren't in the previous report seem to come from , which is already fixed.
And it seems it's only 2 new crates that depend on this version of . So while post-monomorphization errors are tough errors to trigger and find consistently, the results are at least encouraging. It can also be noted that the rough "evaluation of constant failed" error in the OP, has since improved on nightly, to somewhat acceptable levels. <details<summaryHere's how it looks now</summary</detailsAnd could be improved still if we, for example, specialized in the handful of actually used widths.


Question: <ins> Version 1.54.0 (2021-07-29) ============================ Language ----------------------- - [You can now use macros for values in built-in attribute macros.][83366] While a seemingly minor addition on its own, this enables a lot of powerful functionality when combined correctly. Most notably you can now include external documentation in your crate by writing the following. ```rust #![doc = include_str!("README.md")] ``` You can also use this to include auto-generated modules: ```rust #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod generated; ``` - [You can now cast between unsized slice types (and types which contain unsized slices) in `const fn`.][85078] - [You can now use multiple generic lifetimes with `impl Trait` where the lifetimes don't explicitly outlive another.][84701] In code this means that you can now have `impl Trait<'a, 'b>` where as before you could only have `impl Trait<'a, 'b> where 'b: 'a`. Compiler ----------------------- - [Rustc will now search for custom JSON targets in `/lib/rustlib/<target-triple>/target.json` where `/` is the "sysroot" directory.][83800] You can find your sysroot directory by running `rustc --print sysroot`. - [Added `wasm` as a `target_family` for WebAssembly platforms.][84072] - [You can now use `#[target_feature]` on safe functions when targeting WebAssembly platforms.][84988] - [Improved debugger output for enums on Windows MSVC platforms.][85292] - [Added tier 3* support for `bpfel-unknown-none` and `bpfeb-unknown-none`.][79608] * Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries ----------------------- - [`panic::panic_any` will now `#[track_caller]`.][85745] - [Added `OutOfMemory` as a variant of `io::ErrorKind`.][84744] - [ `proc_macro::Literal` now implements `FromStr`.][84717] - [The implementations of vendor intrinsics in core::arch have been significantly refactored.][83278] The main user-visible changes are a 50% reduction in the size of libcore.rlib and stricter validation of constant operands passed to intrinsics. The latter is technically a breaking change, but allows Rust to more closely match the C vendor intrinsics API. Stabilized APIs --------------- - [`BTreeMap::into_keys`] - [`BTreeMap::into_values`] - [`HashMap::into_keys`] - [`HashMap::into_values`] - [`arch::wasm32`] - [`VecDeque::binary_search`] - [`VecDeque::binary_search_by`] - [`VecDeque::binary_search_by_key`] - [`VecDeque::partition_point`] Cargo ----------------------- - [Added the `--prune <spec>` option to `cargo-tree` to remove a package from the dependency graph.][cargo/9520] - [Added the `--depth` option to `cargo-tree` to print only to a certain depth in the tree ][cargo/9499] - [Added the `no-proc-macro` value to `cargo-tree --edges` to hide procedural macro dependencies.][cargo/9488] - [A new environment variable named `CARGO_TARGET_TMPDIR` is available.][cargo/9375] This variable points to a directory that integration tests and benches can use as a "scratchpad" for testing filesystem operations. [79608]: https://github.com/rust-lang/rust/pull/79608 [84988]: https://github.com/rust-lang/rust/pull/84988 [84701]: https://github.com/rust-lang/rust/pull/84701 [84072]: https://github.com/rust-lang/rust/pull/84072 [85745]: https://github.com/rust-lang/rust/pull/85745 [84744]: https://github.com/rust-lang/rust/pull/84744 [85078]: https://github.com/rust-lang/rust/pull/85078 [84717]: https://github.com/rust-lang/rust/pull/84717 [83800]: https://github.com/rust-lang/rust/pull/83800 [83366]: https://github.com/rust-lang/rust/pull/83366 [83278]: https://github.com/rust-lang/rust/pull/83278 [85292]: https://github.com/rust-lang/rust/pull/85292 [cargo/9520]: https://github.com/rust-lang/cargo/pull/9520 [cargo/9499]: https://github.com/rust-lang/cargo/pull/9499 [cargo/9488]: https://github.com/rust-lang/cargo/pull/9488 [cargo/9375]: https://github.com/rust-lang/cargo/pull/9375 [`BTreeMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_keys [`BTreeMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_values [`HashMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_keys [`HashMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_values [`arch::wasm32`]: https://doc.rust-lang.org/core/arch/wasm32/index.html [`VecDeque::binary_search`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search [`VecDeque::binary_search_by`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by [`VecDeque::binary_search_by_key`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by_key [`VecDeque::partition_point`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.partition_point </ins> Version 1.53.0 (2021-06-17) ============================

It would allow mentioning the range bounds in the error message (or we could do some of the const fn string formatting hacks here of course).
Closing as working as intended. The error message has been improved, and a description of the potential breakage will be included in the 1.54 release notes ().


Question: //! contains further primitive shared memory types, including [`atomic`] and //! [`mpsc`], which contains the channel types for message passing. //! <ins> //! # Use before and after `main()` //! //! Many parts of the standard library are expected to work before and after `main()`; //! but this is not guaranteed or ensured by tests. It is recommended that you write your own tests //! and run them on each platform you wish to support. //! This means that use of `std` before/after main, especially of features that interact with the //! OS or global state, is exempted from stability and portability guarantees and instead only //! provided on a best-effort basis. Nevertheless bug reports are appreciated. //! //! On the other hand `core` and `alloc` are most likely to work in such environments with //! the caveat that any hookable behavior such as panics, oom handling or allocators will also //! depend on the compatibility of the hooks. //! //! Some features may also behave differently outside main, e.g. stdio could become unbuffered, //! some panics might turn into aborts, backtraces might not get symbolicated or similar. //! //! Non-exhaustive list of known limitations: //! //! - after-main use of thread-locals, which also affects additional features: //!   - [`thread::current()`] //!   - [`thread::scope()`] //!   - [`sync::mpsc`] //! - before-main stdio file descriptors are not guaranteed to be open on unix platforms //! //! </ins> //! [I/O]: io //! [`MIN`]: i32::MIN //! [`MAX`]: i32::MAX

All existing standard library documentation implicitly assumes that the APIs are being used between the start of a Rust and end of . For example  does not document any indication that the function would panic. It does not need to document that, because the function cannot panic, as long as the call occurs within the duration of . However it's possible to observe a panic like this: (Related PR and discussion: ) In general using the standard library from an callback, or before through a static constructor, is UB: according to "we can't really guarantee anything specific happens [...]; at least not in a cross-platform way." Is this worth calling out centrally as a caveat to all other documentation of the standard library? At the top level of the whole crate (it would perhaps be more prominent than it deserves), at the module level, or in the Reference? Certainly for , , , the expectation users need to have is that nothing in there will work outside of . Are there APIs it makes sense to carve out as being permissible outside of ? Stuff like , , , , etc. We'd maybe need to do research into how constructors and atexit are being used in the wild. For example the crate relies on , , and to be usable before : It seems obvious that those things should work but there isn't documentation which guarantees it. I assume that makes the crate technically unsound as written.
IMHO, core types should work in whatever context but libstd is more dicey. It more explicitly has a runtime or three (e.g. Rust's, libc's and the OS's). So at a minimum anything in the modules , , , , , , , etc should be regarded with suspicion unless documented otherwise. In summary, my thoughts are: is fine depends on the allocator used assumes code is running in main (except for the and possibly stuff)
Core types can still panic and panics do IO.
Hm... how much of an issue is that? Panics don't have to do I/O (e.g. if stderr is closed) so if platforms don't support that before or after main then it can be silently skipped, no?
But do we do that properly today? And it's not just IO but also panic hooks which in turn can rely on various other parts of std.
I think it would be fine to document that e.g.


Question: //! contains further primitive shared memory types, including [`atomic`] and //! [`mpsc`], which contains the channel types for message passing. //! <ins> //! # Use before and after `main()` //! //! Many parts of the standard library are expected to work before and after `main()`; //! but this is not guaranteed or ensured by tests. It is recommended that you write your own tests //! and run them on each platform you wish to support. //! This means that use of `std` before/after main, especially of features that interact with the //! OS or global state, is exempted from stability and portability guarantees and instead only //! provided on a best-effort basis. Nevertheless bug reports are appreciated. //! //! On the other hand `core` and `alloc` are most likely to work in such environments with //! the caveat that any hookable behavior such as panics, oom handling or allocators will also //! depend on the compatibility of the hooks. //! //! Some features may also behave differently outside main, e.g. stdio could become unbuffered, //! some panics might turn into aborts, backtraces might not get symbolicated or similar. //! //! Non-exhaustive list of known limitations: //! //! - after-main use of thread-locals, which also affects additional features: //!   - [`thread::current()`] //!   - [`thread::scope()`] //!   - [`sync::mpsc`] //! - before-main stdio file descriptors are not guaranteed to be open on unix platforms //! //! </ins> //! [I/O]: io //! [`MIN`]: i32::MIN //! [`MAX`]: i32::MAX

after main they may want to set an empty (or aborting) panic hook if panicking is possible. I really don't want to be in a situation where the user is in a worse place than if they'd just used .
Could we turn panics into immediate aborts after main? That would also avoid the backtrace printing and symbolication.
I looked through the standard library, and is the only function that has limitation on usage before/after main (in this case, this is only a problem during TLS destruction). This function is also called from , and , which can therefore panic when called during TLS destruction. and might be able to be reworked to avoid this, but this is fundamentally a limitation of since it requires a reference to the current to work. The stack guard used by the stack overflow handler also accesses the same TLS slot as , but since the stack bounds don't have a this could be moved to a separate to properly support stack overflow handling during TLS destruction.
If we're going to make a statement at all then imo we should start out with something more cautious than making solid guarantees since this would be a pretty wide-ranging promise. before/after main behavior is not tested. It is best-effort and if someone relies on it they should have their own tests core and alloc are expected to work because they don't touch OS APIs or global state caveat: user code in any hookable API like panic handlers, global allocators, OOM handler or any future hooks. Especially panics affect a lot of code. we might replace hooks after main? most existing parts of std, backtrace and other things interacting with the OS are expected to work but there may be platform-specific edge-cases and the behavior may change in the future due to changing implementation details or new features that depend more runtime state (e.g. a std threadpool or async runtime) then finally a list of known limitations
Proposed documentation based on my previous comment:


Question: | LL | unsafe extern "C" { | ^^^^^^ <ins> | = note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information = help: add `#![feature(unsafe_extern_blocks)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date </ins> error[E0658]: `unsafe extern {}` blocks and `safe` keyword are experimental --> $DIR/feature-gate-unsafe-extern-blocks.rs:9:5

With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?


Question: ## missing_doc_code_examples <del> This lint is **allowed by default**. It detects when a documentation block </del> <ins> This lint is **allowed by default** and is **nightly-only**. It detects when a documentation block </ins> is missing a code example. For example: ```rust

I wanted to try out the missingdoccodeexamples rustdoc lint, but it seems to be bugged. I tried following the example given in . Steps to reproduce: Create a new crate: Then edit the file: I would now expect to get a linting error when building the crate, since the add function is public, but does not have a code example. However, as well as and completes without any errors.
The lint only works on nightly, the docs should probably be updated.
These docs live in To fix this, add 'and is nightly-only' to the first sentence.
I created PR to update the documentation. Thanks for clarifying. :-)


Question: use std::cmp; <del> use std::string::String; use crate::clean::{self, DocFragment, Item}; </del> <ins> use crate::clean::{self, DocFragment, DocFragmentKind, Item}; </ins> use crate::core::DocContext; use crate::fold::{self, DocFolder}; use crate::passes::Pass;

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: /// let example = Example::new() /// .first("hello") #[cfgattr(not(feature = "one"), doc = " .second("hello")n")] /// .third("hello") /// .build(); /// with I expected to see this: ! Instead, this happened: ! <!-- 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. --: running over the code gives me /// let example = Example::new() /// .first("hello") /// .second("hello") /// .third("hello") /// .build(); ///
As explained on discord, <strikethe attributes aren't applied to doc comments</strike(EDIT: they are applied, the problem seems to be that it results in two doc comments for rustdoc). However, your doc comment is split in two so the second half isn't considered as being inside a code block, explaining why you have this display. Even if shows it as one doc comment, rustdoc sees two of them. <strikeMaybe we should add a warning or something that attributes aren't applied to doc comments... What do you think ?</strike
How can an attribute get applied to a doc comment? Both are, under the hood, attributes, no? I would expect that to be equivalent to expecting to only derive Debug if is passed, which is not how that works. I'm guessing what is true is that attributes directly written don't actually merge with -style comments. Potentially relevant: , ,
Simplified reproducer rust //! foo(); #![doc = " bar();"] //! Checking with 1.31.0 it still ignores it (so likely not related), but checking with 1.21.0 (and 1.0.0) it worked as expected, so somewhere within that range (but I don't have any other versions installed at the moment to check).
Compilation broke somewhere between 1.23.0 (works) 1.24.0 (does not work) I tested it with rust //! let x = r#" #![doc = " bar();"] //! "#; //! assert_eq!


Question: use std::cmp; <del> use std::string::String; use crate::clean::{self, DocFragment, Item}; </del> <ins> use crate::clean::{self, DocFragment, DocFragmentKind, Item}; </ins> use crate::core::DocContext; use crate::fold::{self, DocFolder}; use crate::passes::Pass;

(x, "n bar();n"); //!
They are not supposed to be applied to a doc comment I do not think that. Your example would make sense for which I also consider to be wrong, but I am talking about which should insert the attribute conditionally but that is not the point. It might help to illustrate my thought process; We have some kind of documented item: rust /// let example = Example::new() /// .first() /// .build(); /// and each of those is turned into a doc attribute rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " In a later step those attributes would then be concatenated and parsed as markdown or whatever. I want to use this behavior to document items conditionally, depending on which features the crate user has enabled. One way to do this would be to do rust let example = Example::new() .first() .build(); rust let example = Example::new() .first() .second() .build(); but that would blow up the source code with many duplicate lines, where only some minor things were changed. So I thought that it might make more sense to conditionally include a doc comment like this: rust /// let example = Example::new() /// .first() #[cfgattr(feature = "one", doc = " .second()")] /// .build(); /// which would turn into rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .second()"] #[doc = " .build();"] #[doc = " or rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " depending on whether the feature is enabled. So the attribute should not be inserted and not applied to the following doc comment. The weird thing is that the manually expanded version is working as expected. rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[cfg_attr(feature = "one", doc = " .second()")] #[doc = " .build();"] #[doc = " but this is very unhandy to work with :/
I was randomly looking at passes for another reason and noticed what is likely the source of this issue.


Question: use std::cmp; <del> use std::string::String; use crate::clean::{self, DocFragment, Item}; </del> <ins> use crate::clean::{self, DocFragment, DocFragmentKind, Item}; </ins> use crate::core::DocContext; use crate::fold::{self, DocFolder}; use crate::passes::Pass;

There are two relevant passes: runs second and removes leading columns of whitespace from the docs. This runs on a single "doc fragment" at a time, because of merging that normally means the entire documentation string, but since sugared and raw docs aren't merged they remain as separate fragments and use their own widths of leading whitespace to strip.
That also matches up with first released in 1.24 which introduced this distinction between doc kinds in order to fix , which IMO was user error in not matching the indent depth.


Question: Available passes for running rustdoc: check-custom-code-classes - check for custom code classes without the feature-gate enabled check_doc_test_visibility - run various visibility-related lints on doctests <ins> strip-aliased-non-local - strips all non-local private aliased items from the output </ins> strip-hidden - strips all `#[doc(hidden)]` items from the output strip-private - strips all private items from a crate which cannot be seen externally, implies strip-priv-imports strip-priv-imports - strips all private import statements (`use`, `extern crate`) from a crate

I tried this code: with and . I expected to see this happen: No internal fields of the should be displayed as users won't be able to use the fields, making their appearance confusing and useless. Instead, this happened: The internal fields of the are displayed ! Real impact as can be seen . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
labels +T-rustdoc +A-rustdoc-ui -needs-triage claim
Dupe of and more discussion there


Question: Available passes for running rustdoc: check-custom-code-classes - check for custom code classes without the feature-gate enabled check_doc_test_visibility - run various visibility-related lints on doctests <ins> strip-aliased-non-local - strips all non-local private aliased items from the output </ins> strip-hidden - strips all `#[doc(hidden)]` items from the output strip-private - strips all private items from a crate which cannot be seen externally, implies strip-priv-imports strip-priv-imports - strips all private import statements (`use`, `extern crate`) from a crate

Using to document private types of the current workspace exposes external types private implementation details (in this case private fields). I would expect the expansion to limit itself to public fields. e.g. gives ! <details<summary<coderustc --version --verbose</code</summary<p</p</detailsr?
I suppose it's "ok" since you used the option. I'll add it to the next rustdoc team meeting agenda to be confirmed by the team.
Rendered output for anyone wondering: !
I'll summarize the exchange I had with Guillaume on matrix. First, the flag I'm talking about is the one you provide to . does not blindly pass the flag to but only for crates you own in your current workspace. That means that when documenting your workspace with . Private items, fields of your crates are shown contrary to your dependencies. Regarding design, it seems weird to me that aliased type expansion shows private implementation details of dependencies (e.g. for the given example). I would personally expect something like:


Question: mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {

<!-- 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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?


Question: mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {

Pretty much what the title says, I've narrowed it down to and today's nightly with the following: I've attached some backtraces.
probably duplicate of but made more prevalent by next solver
Is it possible to provide a link to or a snippet of a reproducer? I know it probably happens to various crates, but it still would be nice to have something that reproduces.
See for an attached repro.
The repro case is basically the same as , but with other crates mentioned in the ICE logs from the issue comment.


Question: mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {

Compile with latest Nightly got ICE like below: when compiling in code OS: x86_64-apple-darwin
cc
Wyvern, could you provide some sort of reproducer? A link to some commit in some repository or better yet a smaller stripped down version of it?
Can you provide an example which triggers this behavior?
I'm not sure which commit/PR of lead to this crash, sometimes it compiled successfully, sometimes it not. Add this info to original post, hope to help investigation.
are you running with greater than 1? The cache is broken when used with more than 1 thread (which we should fix)
Sorry, I wasn't clear. I meant a link to your project (the project you are trying to compile) if publicly accessible / not proprietary.
I can hit plenty of these while fuzzing with -Zthreads so yeah its probably that.
Yeah, I think was the culprit. Comment out this option crashes disappears.
the easiest fix to rustc is to just disable this assert when we're using more than 1 thread. I've only it for debugging purposes to detect cases where we unnecessarily recompute cache entries
just hit this while trying to bootstrap with Zthreads :sweat_smile:
cc as this also showed up in your ci test run ^^
When I just disable this assert, all relevant UI tests passed with no other bugs or ICE
samle code that triggers this in around 5 of 6 cases with -Zthreads=16


Question: //~ TRANS_ITEM fn unsizing::{{impl}}[3]::foo[0] let _wrapper_sized = wrapper_sized as Wrapper<Trait>; } <del> //~ TRANS_ITEM drop-glue i8 </del>

I found that current rustc 1.13.0-nightly can't compile'Rust by Example - 8.2.5 As output parameters' code, both on my linux pc and . I tried this code: see Executing code above on Rust Playground produces the message below when selecting nightly. ( but stable and beta do not produce this error). error: linking with failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib" "./out.0.o" "-o" "./out" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libstd-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libpanicunwind-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libunwind-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/librand-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libcollections-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/librustcunicode-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liballoc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liballocjemalloc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liblibc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libcore-" "-l" "dl" "-l" "pthread" "-l" "gccs" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt" = note: ./out.0.o: In function drop::hf3564cae7b79f1cb': (.text.


Question: //~ TRANS_ITEM fn unsizing::{{impl}}[3]::foo[0] let _wrapper_sized = wrapper_sized as Wrapper<Trait>; } <del> //~ TRANS_ITEM drop-glue i8 </del>

ZN4drop17hf3564cae7b79f1cbE+0xd): undefined reference toLTGTasGT$::drop::h4c07c16183524d21' ./out.0.o: In function drop::hc5f0e028c3876d25': (.text.ZN4drop17hc5f0e028c3876d25E+0xd): undefined reference toLTGTasGT$::drop::h7a8bb753832b1af2' collect2: error: ld returned 1 exit status error: aborting due to previous error Compilation failed. This happens on my Linux Laptop pc as well. This is my laptop's rustc version(installing current latest) . : rustc 1.13.0-nightly ( 2016-08-25) binary: rustc commit-hash: commit-date: 2016-08-25 host: x86_64-unknown-linux-gnu release: 1.13.0-nightly
Nominating since this appears to be a regression.
is still good, does not exist and fails. . Reduced:
This may be a related to . Edit: not a duplicate I think, since was introduced in a different nightly.
Running with the above sample and leads to an ICE in printing a log message
This is from the removal of old trans. We should've been covered by on-demand drop glue generation still, though. cc
Looking at the IR - the missing methods are d, and called from drop methods taking e.g.
Oh, this is bad. The collector needs to know user definitions being instantiated ahead of time (including impls), and these can be used from drop glue which is not guaranteedly known ahead of time. We might need to temporarily detect the shim'd cases in the collector and trigger drop glue generation. cc
I'm looking into a short-term fix right now.
yay! Thanks


Question: LL |     let _y = x; |              ^ | <del> help: a local variable with a similar name exists, consider changing it </del> <ins> help: a local variable with a similar name exists, consider renaming `_x` into `x` </ins> | LL |     let x = 42; |         ~

I tried on Rust 1.76.0: I got the following error: Note that the suggestion has stripped the leading character from the enum's name.
Can confirm this is still present in nightly.
Sounds like fun. Taking a look.
So it is intended this way from what I can see in the source code: Improving the wording would be become to clear the confusion though I think.


Question: <ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66906.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

results in an ICE (): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: .. }, method, <del> )) if Some(recv_ty.def_id()) == pin_did && method.ident.name == sym::new => { </del> <ins> )) if recv_ty.opt_def_id() == pin_did && method.ident.name == sym::new => { </ins> err.span_suggestion( fn_name.span, "use `Box::pin` to pin and box this expression",

<!-- 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. -- On stable the code produces the following error as expected: <details<summary<strongExpected result</strong</summary<p</p</details<!-- 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</detailssearched nightlies: from nightly-2021-10-04 to nightly-2021-10-23 regressed nightly: nightly-2021-10-16 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Also ICEs on beta. label regression-from-stable-to-beta
Interesting, this is rustc now, right? There has been as similar rustdoc ice:
Yes, this can be hit with or for example. I tried running the code in , but it seems to have been fixed by now.
claim I'll try to take a look at this.


Question: fn main() { foo(1, 2, 3); //~^ ERROR this function takes 4 parameters but 3 <del> //~^^ NOTE the following parameter types were expected </del> <ins> //~| NOTE the following parameter types were expected //~| NOTE expected 4 parameters </ins> }

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


Question: /// Mark LLVM function to use provided inline heuristic. #[inline] <del> fn inline(cx: &CodegenCx<'ll, '_>, val: &'ll Value, inline: InlineAttr, requires_inline: bool) { </del> <ins> fn inline(cx: &CodegenCx<'ll, '_>, val: &'ll Value, inline: InlineAttr) { </ins> use self::InlineAttr::*; match inline { Hint => Attribute::InlineHint.apply_llfn(Function, val),

Currently, the compiler is allowed to inline naked functions if it wants to. For a normal function, inlining is fine because the compiler can remove the function prologue/epilogue and the remaining will behave as expected. However for naked functions, the developer provides the prologue/epilogue and those aren't removed by the compiler. This almost surely will result in incorrect behavior. Accordingly I think it would make sense for the compiler to not inline naked functions unless the developer explicitly opted-in.
In the other thread, alistair23 found that
Yes, functions should imply .


Question: <ins> error[E0308]: mismatched types --> $DIR/proper-span-for-type-error.rs:8:5 | LL |     a().await |     ^^^^^^^^^ expected enum `Result`, found `()` | = note:   expected enum `Result<(), i32>` found unit type `()` help: try wrapping the expression in `Ok` | LL |     Ok(a().await) |     +++         + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/


Question: // Because it is `?Sized`, it will always be the last field in memory. // Note: This is a detail of the current implementation of the compiler, // and is not a guaranteed language detail. Do not rely on it outside of std. <del> unsafe { data_offset_align(align_of_val(&*ptr)) } </del> <ins> unsafe { data_offset_align(align_of_val_raw(ptr)) } </ins> } #[inline]

I tried this code: When I run it under , I get this: Creating a reference from such pointer looks suspicious indeed. I could send a pull request that adds a condition there, but I want to ask first if this is being done because „we are , we can“, or if this is something that really should be fixed. : (but I've looked at the git sources and the thing is still there) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it should only be UB to dereference the pointer you get from , so I'm not sure why Miri thinks there's UB happening. Just in case, prioritize
Because that pointer is being turned into a reference to feed to internally. And references are supposed to be always valid.
Looks like fixed this for but missed it in .
Yes, seems this needs to use .
I renamed the issue to reflect that the bug is actually in (which calls).
Cc
Assuming you use the default flags for Miri, that change should not be required to make Miri pass, so I'd be surprised if doing the same change for would make any difference here. If it does, that seems like a bug in Miri that I should investigate.
Ah, but the in is indeed a problem (the PR was mostly about so I got side-tracked; the is what should not have any effect here). Miri ensures that references are at least dereferencable, so yeah that would explain the problem here. Good catch!
Yep, I apparently missed this somehow in . Fixing the indicated line to use should be enough to fix it; I'm preparing the patch currently. claim
Hm, Miri still complains, even after the fix landed... it seems Miri doesn't like being called with dangling pointers. I'll have to look into this.
IIRC, when , I changed the type of the intrinsic to take a raw pointer rather than a reference, but miri wasn't touched, so that would make sense miri's still expecting a proper reference.
Patch arrived really fast, we are assigning "post-mortem" a priority of as discussed as part of the and removing .


Question: #![feature(ptr_metadata)] #![feature(once_cell)] #![feature(unsized_tuple_coercion)] <del> #![feature(nonzero_leading_trailing_zeros)] </del> #![feature(const_option)] #![feature(integer_atomics)] #![feature(slice_group_by)]

Tracking issue for trailingzeros and leadingzeros for non zero types as introduced by . The feature gate for the issue is . On many architectures, this functions can perform better than trailingzeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
It seems on my (common) architecture it doesn't give an advantage: : : So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough?
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)
merge cc
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] No concerns currently listed. 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.
: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.
started to make the stabilization PR but hit a problem I think that constcttz needs to be stabilized for this to be stabilized from //! If an intrinsic is supposed to be used from a with a attribute, //! the intrinsic's attribute must be , too. Such a change should not be done //! without T-lang consulation, because it bakes a feature into the language that cannot be //! replicated in user code without compiler support.


Question: } #[test] <ins> #[cfg(unix)] fn set_get_unix_permissions() { use os::unix::fs::PermissionsExt; let tmpdir = tmpdir(); let filename = &tmpdir.join("set_get_unix_permissions"); check!(fs::create_dir(filename)); let mask = 0o7777; check!(fs::set_permissions(filename, fs::Permissions::from_mode(0))); let metadata0 = check!(fs::metadata(filename)); assert_eq!(mask & metadata0.permissions().mode(), 0); check!(fs::set_permissions(filename, fs::Permissions::from_mode(0o1777))); let metadata1 = check!(fs::metadata(filename)); assert_eq!(mask & metadata1.permissions().mode(), 0o1777); } #[test] </ins> #[cfg(windows)] fn file_test_io_seek_read_write() { use os::windows::fs::FileExt;

On linux, , then run: This changes the permissions of to . Is this expected? masks away everything other than the lower 3 triads when it calls out to this code: Then sends these mode bits into into chmod which considers four triads, not three. Possibly useful references: and Should we change Metadata.permissions to preserve that triad, maybe by masking with instead of ?
I guess the solution depends on whether Unix's std::fs::Permissions is supposed to care about 9 bits or 12 (this is not an implementation detail since it's exposed to the programmer via of PermissionsExt). any thoughts on this?
It seems to me like we should extend the mask to the full 12 bits.
Seems reasonable to me to avoid masking where it makes sense!


Question: LL - fn f1<W: ?Sized, X: ?Sized, Y: ?Sized, Z: ?Sized>(x: &X) { LL + fn f1<W: ?Sized, X: ?Sized, Y, Z: ?Sized>(x: &X) { | <ins> help: consider borrowing here | LL |     let y: &Y; |            + </ins> error[E0277]: the size for values of type `X` cannot be known at compilation time --> $DIR/unsized6.rs:7:12

I tried compiling this code: which resulted in the following output of rustc: So the compiler says So I tried adding a borrow and recompiling the code: which resulted in: so the compiler says and so I'm stuck in a loop. The compiler can't decide whether I should borrow or not. As a newbie to Rust, this is very frustrating and the opposite of helpful, it just confuses me further. Please fix this indecisiveness :) :
For reference, what you likely want to do is one of the following which means they cannot be the type of a local binding. You can give a binding a slice type (), because that's morally equivalent to a pointer (with sizing info), which has a compile time determined size, as all borrows are .
Current output: After :


Question: &Path("lib/libstd.so")); assert_eq!(res.to_str(), ~"@executable_path/../lib"); } <ins> #[test] fn test_get_absolute_rpath() { let res = get_absolute_rpath(&Path("lib/libstd.so")); debug!("test_get_absolute_rpath: %s vs. %s", res.to_str(), os::make_absolute(&Path("lib")).to_str()); assert_eq!(res, os::make_absolute(&Path("lib"))); } </ins> }

These are configured something like
I am not sure why this happens off hand, but when bootstrapping the non-build-triple compilers artifacts are copied from e.g. to .


Question: } #[derive(Diagnostic)] <ins> #[diag(parse_at_dot_dot_in_struct_pattern)] pub(crate) struct AtDotDotInStructPattern { #[primary_span] pub span: Span, #[suggestion(code = "", style = "verbose", applicability = "machine-applicable")] pub remove: Span, pub ident: Ident, } #[derive(Diagnostic)] #[diag(parse_at_in_struct_pattern)] #[note] #[help] pub(crate) struct AtInStructPattern { #[primary_span] pub span: Span, } #[derive(Diagnostic)] </ins> #[diag(parse_dot_dot_dot_for_remaining_fields)] pub(crate) struct DotDotDotForRemainingFields { #[primary_span]

This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim


Question: // inferred to a region bound in the method argument. If this program // were accepted, then the closure passed to `s.f` could escape its // argument. <ins> //@ run-rustfix </ins> struct S;

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'', 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [mirborrowck] borrow-checking --
ICEs on nightly and beta, but not on stable. Minimized further: <details<summaryProgram output</summary</details
The ICE is another one from , cc
Still reproduces on 1.81.0-nightly (2024-06-13 ) -E-needs-test
I'll look into it later today.


Question: // inferred to a region bound in the method argument. If this program // were accepted, then the closure passed to `s.f` could escape its // argument. <ins> //@ run-rustfix </ins> struct S;

: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.


Question: let libdir = builder.sysroot_libdir(target_compiler, target); let hostdir = builder.sysroot_libdir(target_compiler, compiler.host); add_to_sysroot(builder, &libdir, &hostdir, &libstd_stamp(builder, compiler, target)); <ins> if compiler.stage == 0 { // special handling for stage0, to make `rustup toolchain link` and `x dist --stage 0` // work for stage0-sysroot let sysroot = builder.out.join(&compiler.host.triple).join("stage0-sysroot"); let host_lib_dir = builder.initial_rustc.ancestors().nth(2).unwrap().join("lib"); let host_bin_dir = builder.out.join(&builder.initial_rustc.parent().unwrap()); let host_codegen_backends = host_lib_dir.join("rustlib").join(&compiler.host.triple).join("codegen-backends"); let sysroot_bin_dir = sysroot.join("bin"); let sysroot_lib_dir = sysroot.join("lib"); let sysroot_codegen_backends = builder.sysroot_codegen_backends(compiler); // Create the `bin` directory in stage0-sysroot t!(fs::create_dir_all(&sysroot_bin_dir)); // copy bin files from `builder.initial_rustc/./` to `stage0-sysroot/bin` if let Ok(files) = fs::read_dir(&host_bin_dir) { for file in files { let file = t!(file); if file.file_name() == "rustfmt" { // This is when `rustc` and `cargo` are set in `config.toml` if !file.path().starts_with(&builder.out) { builder.copy( &file.path().into_boxed_path(), &sysroot_bin_dir.join(file.file_name()), ); } else { builder.copy( &builder .out .join(&compiler.host.triple) .join("rustfmt/bin/rustfmt"), &sysroot_bin_dir.join(file.file_name()), ); } } else { builder.copy( &file.path().into_boxed_path(), &sysroot_bin_dir.join(file.file_name()), ); } } } // copy dylib files from `builder.initial_rustc/../lib/*` while excluding the `rustlib` directory to `stage0-sysroot/lib` if let Ok(files) = fs::read_dir(&host_lib_dir) { for file in files { let file = t!(file); let path = file.path(); if path.is_file() && is_dylib(&file.file_name().into_string().unwrap()) && !path.starts_with(sysroot_lib_dir.join("rustlib").into_boxed_path()) { builder.copy(&path, &sysroot_lib_dir.join(path.file_name().unwrap())); } } } t!(fs::create_dir_all(&sysroot_codegen_backends)); // copy `codegen-backends` from `host_lib_dir/rustlib/codegen_backends` to `stage0-sysroot/lib/rustlib/host-triple/codegen-backends` if it exists. if host_codegen_backends.exists() { builder.cp_r(&host_codegen_backends, &sysroot_codegen_backends); } } </ins> } }

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


Question: let libdir = builder.sysroot_libdir(target_compiler, target); let hostdir = builder.sysroot_libdir(target_compiler, compiler.host); add_to_sysroot(builder, &libdir, &hostdir, &libstd_stamp(builder, compiler, target)); <ins> if compiler.stage == 0 { // special handling for stage0, to make `rustup toolchain link` and `x dist --stage 0` // work for stage0-sysroot let sysroot = builder.out.join(&compiler.host.triple).join("stage0-sysroot"); let host_lib_dir = builder.initial_rustc.ancestors().nth(2).unwrap().join("lib"); let host_bin_dir = builder.out.join(&builder.initial_rustc.parent().unwrap()); let host_codegen_backends = host_lib_dir.join("rustlib").join(&compiler.host.triple).join("codegen-backends"); let sysroot_bin_dir = sysroot.join("bin"); let sysroot_lib_dir = sysroot.join("lib"); let sysroot_codegen_backends = builder.sysroot_codegen_backends(compiler); // Create the `bin` directory in stage0-sysroot t!(fs::create_dir_all(&sysroot_bin_dir)); // copy bin files from `builder.initial_rustc/./` to `stage0-sysroot/bin` if let Ok(files) = fs::read_dir(&host_bin_dir) { for file in files { let file = t!(file); if file.file_name() == "rustfmt" { // This is when `rustc` and `cargo` are set in `config.toml` if !file.path().starts_with(&builder.out) { builder.copy( &file.path().into_boxed_path(), &sysroot_bin_dir.join(file.file_name()), ); } else { builder.copy( &builder .out .join(&compiler.host.triple) .join("rustfmt/bin/rustfmt"), &sysroot_bin_dir.join(file.file_name()), ); } } else { builder.copy( &file.path().into_boxed_path(), &sysroot_bin_dir.join(file.file_name()), ); } } } // copy dylib files from `builder.initial_rustc/../lib/*` while excluding the `rustlib` directory to `stage0-sysroot/lib` if let Ok(files) = fs::read_dir(&host_lib_dir) { for file in files { let file = t!(file); let path = file.path(); if path.is_file() && is_dylib(&file.file_name().into_string().unwrap()) && !path.starts_with(sysroot_lib_dir.join("rustlib").into_boxed_path()) { builder.copy(&path, &sysroot_lib_dir.join(path.file_name().unwrap())); } } } t!(fs::create_dir_all(&sysroot_codegen_backends)); // copy `codegen-backends` from `host_lib_dir/rustlib/codegen_backends` to `stage0-sysroot/lib/rustlib/host-triple/codegen-backends` if it exists. if host_codegen_backends.exists() { builder.cp_r(&host_codegen_backends, &sysroot_codegen_backends); } } </ins> } }

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


Question: <ins> // build-fail // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm!("nop" : "+r"("r15")); //~^ malformed inline assembly } } </ins>

Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!


Question: /// # Examples /// /// ```rust <del> /// #![feature(fmt_as_str)] /// </del> /// use std::fmt::Arguments; /// /// fn write_str(_: &str) { /* ... */ }

Tracking issue for (), gated by .
I don't quite understand fmt internals, but Make fmt::Arguments::asstr() return a 'static str. seems unnecessarily restrictive. And it breaks which depends on hidden apis e.g. Arguments::newv1
cannot be generated at runtime because it cannot safely be done. So returns makes sense.
I'd like to be able to use this in the log crate to correctly implement a codegen optimization that doesn't really work otherwise: fcp 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] [x] [ ] No concerns currently listed. 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.
This SGTM. One question though. Are we sure that the bound will always be correct here?
is the result from parsing a formatting string at compile time. In the future, this might not always be a literal but might be a too. But a non-static/constant format string will be a very different beast.
That's what I figured, but wanted to make sure it was explicitly addressed.
:bell: This is now entering its final comment period, as per the . :bell:
Does this make any guarantees about when is returned? I've been interested in redoing the macro to be much more intelligent (and thus performant), but obviously don't know when it's possible to return something statically knowable.
Currently it returns Some for only. But my plan is to extend that also to , , and possibly also things like , etc. See
Yeah, I see that from looking at the source code. I was more inquiring about whether it would be considered breaking to go from returning to returning . I don't suspect anything would be out-of-reach when reimplementing the macro, but you never know.
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.


Question: /// # Examples /// /// ```rust <del> /// #![feature(fmt_as_str)] /// </del> /// use std::fmt::Arguments; /// /// fn write_str(_: &str) { /* ... */ }

I think you'd generally want to use it as an optimization only, but we can probably guarantee that it will return Some for certain cases in particular (e.g. ).
This function seems particularly bad for compressed formatting strings and breaks the otherwise clean abstraction.