There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
Rollup of 5 pull requests
Successful merges:
- #127273 (Fix `DebugParser`.)
- #127587 (Report usage of lib features in ast validation)
- #127592 (doc: Suggest `str::repeat` over `iter::repeat().take().collect()`)
- #127630 (Remove lang feature for type ascription (since it's a lib feature now))
- #127711 (Add regression test for a gce + effects ICE)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for a gce + effects ICE
Fixes#125770
I'm not *exactly* sure why this stopped ICEing, I assume its something to do with the fact that there used to be a generic parameter on `Add` for the host generic and we have mismatched args here, which #125608 made no longer later cause issues. But now the desugaring is also different so? 🤷♀️
r? `@fee1-dead`
Remove lang feature for type ascription (since it's a lib feature now)
It's not necessary since it's a library feature now, via the type ascription macro. We can't (and shouldn't) register it as a removed feature since I think that would give "this feature has been removed" errors even for people using the macro (well, I'm pretty sure, though I didn't check).
r? `@Nilstrieb`
Report usage of lib features in ast validation
No idea why it was split between ast validation for lang features and a later pass for lang features.
r? `@Nilstrieb`
Fix `DebugParser`.
I tried using this and it didn't work at all. `prev_token` is never eof, so the accumulator is always false, which means the `then_some` always returns `None`, which means `scan` always returns `None`, and `tokens` always ends up an empty vec. I'm not sure how this code was supposed to work.
(An aside: I find `Iterator::scan` to be a pretty wretched function, that produces code which is very hard to understand. Probably why this is just one of two uses of it in the entire compiler.)
This commit changes it to a simpler imperative style that produces a valid `tokens` vec.
r? `@workingjubilee`
Merge Apple `std::os` extensions modules into `std::os::darwin`
The functionality available on Apple platforms are very similar, and were (basically) duplicated for each platform.
This PR rectifies that by merging the code into one module.
Ultimately, I've done this to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Publically exposing these to tvOS/watchOS/visionOS targets is considered in https://github.com/rust-lang/rust/pull/123723, but that seems to be dragging out, and in any case I think it makes sense to do the refactor separately from stabilization.
r? libs
Fixes https://github.com/rust-lang/rust/issues/121640 and https://github.com/rust-lang/rust/issues/124825.
The functionality available on Apple platforms are very similar, and
were duplicated for each platform.
Additionally, this fixes a warning when compiling the standard library
for tvOS, watchOS and visionOS by marking the corresponding code as
dead code.
Gate the type length limit check behind a nightly flag
Effectively disables the type length limit by introducing a `-Zenforce-type-length-limit` which defaults to **`false`**, since making the length limit actually be enforced ended up having a worse fallout than expected. We still keep the code around, but the type length limit attr is now a noop (except for its usage in some diagnostics code?).
r? `@lcnr` -- up to you to decide what team consensus we need here since this reverses an FCP decision.
Reopens#125460 (if we decide to reopen it or keep it closed)
Effectively reverses the decision FCP'd in #125507Closes#127346
Rollup of 5 pull requests
Successful merges:
- #127083 (Add release notes for 1.80)
- #127322 (handle ci-rustc incompatible options during config parse)
- #127697 (use std for file mtime and atime modifications)
- #127704 (Fix minor typos in std::process doc on Win argv)
- #127710 (clarify the meaning of the version number for accepted/removed features)
r? `@ghost`
`@rustbot` modify labels: rollup
use std for file mtime and atime modifications
Since 1.75 std provides an interface to set access and modified times on files. This change replaces the external dependency previously used for these operations with the corresponding std functions.
handle ci-rustc incompatible options during config parse
This PR ensures that `config.toml` does not use CI rustc incompatible options when CI rustc is enabled (just like [ci-llvm checks](e2cf31a614/src/bootstrap/src/core/config/config.rs (L1809-L1836))). Some options can change compiler's behavior in certain scenarios. If we don't check these incompatible options, CI runners using CI rustc might ignore options we have explicitly set. This could be dangerous as we might think a rustc test passed with option T but in fact it wasn't tested with option T.
Later in https://github.com/rust-lang/rust/pull/122709, I will disable CI rustc if any of those options were used (similar to [this approach](dd2c24aafd/src/ci/run.sh (L165-L169))). If CI runners fail because of these checks, it means the logic in run.sh isn't covering the incompatible options correctly (since any incompatible option should turn off CI rustc).
The list may not be complete, but should be a good first step as it's better than nothing!
Blocker for https://github.com/rust-lang/rust/pull/122709
Add release notes for 1.80
cc `@rust-lang/release`
r? `@Mark-Simulacrum`
I tended to err on the side of leaving more stuff in since I don't have a perfect idea of what should or should not be in the release notes right now.
Only track mentioned places for jump threading
This PR aims to reduce the state space size in jump threading and dataflow const-prop opts.
The current implementation walks the types of all locals, and creates a place for each possible projection. This can easily lead to a large number of places and tracked values, most being useless to the actual pass.
With this PR, we instead collect places that appear syntactically in the MIR (first commit). However, this is not sufficient (second commit), and we miss places that we could track in aggregate assignments. The third commit tracks such assignments to mirror place projections, see the inline comment.
This is complementary to https://github.com/rust-lang/rust/pull/127036
r? `@oli-obk`
Use ManuallyDrop in BufWriter::into_parts
The fact that `mem::forget` takes by value means that it interacts very poorly with Stacked Borrows; generally users think of calling it as a no-op, but in Stacked Borrows, the field retagging tends to cause surprise tag invalidation.
Clear `inner_attr_ranges` regularly.
There's a comment saying we don't do it for performance reasons, but it doesn't actually affect performance.
The commit also tweaks the control flow, to make clearer that two code paths are mutually exclusive.
r? ````@petrochenkov````
use "bootstrap" instead of "rustbuild" in comments and docs
Let's stick with the single name "bootstrap" to refer to the bootstrap project to avoid confusion. This should make it clearer, especially for new contributors.
Add FileCheck annotations to mir-opt/dest-prop tests
Part of https://github.com/rust-lang/rust/issues/116971, adds FileCheck annotations to MIR-opt tests in tests/mir-opt/dest-prop.
I would like some feedback. Also, I don't know how to approach `union.rs`. I couldn't figure out what it is testing.
r? cjgillot
using correct tool mode for `run-make-support` crate
We don't need to ensure std (and rustc) for testing run-make-support's unit tests. Using stage 0 compiler is already enough and speeds up `x test run-make-support` invocations on a clean build.
Remove memory leaks in doctests in `core`, `alloc`, and `std`
cc `@RalfJung` https://github.com/rust-lang/rust/issues/126067https://github.com/rust-lang/miri/issues/3670
Should be no actual *documentation* changes[^1], all added/modified lines in the doctests are hidden with `#`,
This PR splits the existing memory leaks in doctests in `core`, `alloc`, and `std` into two general categories:
1. "Non-focused" memory leaks that are incidental to the thing being documented, and/or are easy to remove, i.e. they are only there because preventing the leak would make the doctest less clear and/or concise.
- These doctests simply have a comment like `# // Prevent leaks for Miri.` above the added line that removes the memory leak.
- [^2]Some of these would perhaps be better as part of the public documentation part of the doctest, to clarify that a memory leak can happen if it is not otherwise mentioned explicitly in the documentation (specifically the ones in `(A)Rc::increment_strong_count(_in)`).
2. "Focused" memory leaks that are intentional and documented, and/or are possibly fragile to remove.
- These doctests have a `# // FIXME` comment above the line that removes the memory leak, with a note that once `-Zmiri-disable-leak-check` can be applied at test granularity, these tests should be "un-unleakified" and have `-Zmiri-disable-leak-check` enabled.
- Some of these are possibly fragile (e.g. unleaking the result of `Vec::leak`) and thus should definitely not be made part of the documentation.
This should be all of the leaks currently in `core` and `alloc`. I only found one leak in `std`, and it was in the first category (excluding the modules `@RalfJung` mentioned in https://github.com/rust-lang/rust/issues/126067 , and reducing the number of iterations of [one test](https://github.com/rust-lang/rust/blob/master/library/std/src/sync/once_lock.rs#L49-L94) from 1000 to 10)
[^1]: assuming [^2] is not added
[^2]: backlink
Windows: Add experimental support for linking std-required system DLLs using raw-dylib
For Windows, this allows std to define system imports without needing the user to have import libraries. It's intended for this to become the default.
For now it's an experimental feature so it can be tested using build-std.
Since 1.75 std provides an interface to set access and modified times on files.
This change replaces the external dependency previously used for these operations
with the corresponding std functions.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Stabilize const unchecked conversion from u32 to char
Closes https://github.com/rust-lang/rust/issues/89259.
The functions in this PR were left out of the initial set of `feature(const_char_convert)` stabilizations in https://github.com/rust-lang/rust/pull/102470, but have since been unblocked by https://github.com/rust-lang/rust/pull/118979.
If `unsafe { from_u32_unchecked(u) }` is called in const with a value for which `from_u32(u)` returns None, we get the following compile error.
```rust
fn main() {
let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
}
```
```console
error[E0080]: it is undefined behavior to use this value
--> src/main.rs:2:19
|
2 | let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ constructing invalid value: encountered 0x0000d800, but expected a valid unicode scalar value (in `0..=0x10FFFF` but not in `0xD800..=0xDFFF`)
|
= note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
= note: the raw bytes of the constant (size: 4, align: 4) {
00 d8 00 00 │ ....
}
note: erroneous constant encountered
--> src/main.rs:2:13
|
2 | let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
We don't need to ensure std (and rustc) for testing run-make-support's
unit tests. Using stage 0 compiler is already enough and speeds up
`x test run-make-support` invocations on a clean build.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
std::unix::fs: removing, now useless, layers predating macOs 10.10.
fdopendir, openat and unlinkat are available since yosemite but we support sierra as minimum.
