In #120904, `MatchPair` became able to store other match pairs as children,
forming a tree. That has made the old name confusing, so this patch renames the
type to `MatchPairTree`.
maintain the given order on step execution
Previously step execution disregarded the CLI order and this change executes the given steps in the order specified on CLI.
For example, running `x $kind a b c` will execute `$kind` step for `a`, then `b`, then `c` crates in the specified order.
Fixes#126165
cc `@matthiaskrgr`
Previously step execution disregarded the CLI order and this change executes the given
steps in the order specified on CLI.
For example, running `x $kind a b c` will execute `$kind` step for `a`, then `b`, then `c` crates
in the specified order.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
bootstrap: open `llvm-config` as r+w
This previously failed on Windows and prevented building on Windows for compiler stuff because the `llvm-config` file was open as read-only.
Tested locally on a Windows machine.
Fixes#127849.
Prevent double reference in generic futex
In the Windows futex implementation we were a little lax at allowing references to references (i.e. `&&`) which can lead to deadlocks due to reading the wrong memory address. This uses a trait to tighten the constraints and ensure this doesn't happen.
r? libs
Make more Windows functions `#![deny(unsafe_op_in_unsafe_fn)]`
As part of #127747, I've evaluated some more Windows functions and added `unsafe` blocks where necessary. Some are just trivial wrappers that "inherit" the full unsafety of their function, but for others I've added some safety comments. A few functions weren't actually unsafe at all. I think they were just using `unsafe fn` to avoid an `unsafe {}` block.
I'm not touching `c.rs` yet because that is partially being addressed by another PR and also I have plans to further reduce the number of wrapper functions we have in there.
r? libs
This function is purely informative, answering where a stack starts.
This is a safe operation, even if an answer requires unsafe code,
and even if the result is some unsafe code decides to trust the answer.
It also doesn't need to fetch the PAGE_SIZE when its caller just did so!
Let's complicate its signature and in doing so simplify its operation.
This allows sprinkling around #[forbid(unsafe_op_in_unsafe_fn)]
Rollup of 9 pull requests
Successful merges:
- #125206 (Simplify environment variable examples)
- #126271 (Skip fast path for dec2flt when optimize_for_size)
- #126776 (Clean up more comments near use declarations)
- #127444 (`impl Send + Sync` and override `count` for the `CStr::bytes` iterator)
- #127512 (Terminate `--print link-args` output with newline)
- #127792 (std: Use `read_unaligned` for reads from DWARF)
- #127807 (Use futex.rs for Windows thread parking)
- #127833 (zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`)
- #127836 (std: Forbid unwrapped unsafe ops in xous and uefi modules)
Failed merges:
- #127813 (Prevent double reference in generic futex)
r? `@ghost`
`@rustbot` modify labels: rollup
This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:
- `ConstArgKind` gets a new `Path` variant, and all const params are now
represented using it. Non-param paths still use `ConstArgKind::Anon`
to prevent this change from getting too large, but they will soon use
the `Path` variant too.
- `ConstArg` gets a distinct `hir_id` field and its own variant in
`hir::Node`. This affected many parts of the compiler that expected
the parent of an `AnonConst` to be the containing context (e.g., an
array repeat expression). They have been changed to check the
"grandparent" where necessary.
- Some `ast::AnonConst`s now have their `DefId`s created in
rustc_ast_lowering rather than `DefCollector`. This is because in some
cases they will end up becoming a `ConstArgKind::Path` instead, which
has no `DefId`. We have to solve this in a hacky way where we guess
whether the `AnonConst` could end up as a path const since we can't
know for sure until after name resolution (`N` could refer to a free
const or a nullary struct). If it has no chance as being a const
param, then we create a `DefId` in `DefCollector` -- otherwise we
decide during ast_lowering. This will have to be updated once all path
consts use `ConstArgKind::Path`.
- We explicitly use `ConstArgHasType` for array lengths, rather than
implicitly relying on anon const type feeding -- this is due to the
addition of `ConstArgKind::Path`.
- Some tests have their outputs changed, but the changes are for the
most part minor (including removing duplicate or almost-duplicate
errors). One test now ICEs, but it is for an incomplete, unstable
feature and is now tracked at #127009.
This is needed to track anon const parents properly once we implement
`ConstArgKind::Path` (which requires moving anon const def-creation
outside of `DefCollector`):
Why do we need this in addition to [`Self::current_hir_id_owner`]?
Currently (as of June 2024), anonymous constants are not HIR owners;
however, they do get their own DefIds. Some of these DefIds have to be
created during AST lowering, rather than def collection, because we
can't tell until after name resolution whether an anonymous constant
will end up instead being a [`rustc_hir::ConstArgKind::Path`]. However,
to compute which generics are available to an anonymous constant nested
inside another, we need to make sure that the parent is recorded as the
parent anon const, not the enclosing item. So we need to track parent
defs differently from HIR owners, since they will be finer-grained in
the case of anon consts.
zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`
This also adds an additional `unsafe` block to address compiler errors.
This PR is intended to address https://github.com/rust-lang/rust/issues/127747 for the zkvm target.
Use futex.rs for Windows thread parking
If I'm not overlooking anything then the Windows 10+ thread parking implementation is practically the same as the futex.rs implementation. So we may as well use the same implementation for both. The old version is still kept around for Windows 7 support.
r? ````@joboet```` if you wouldn't mind double checking I've not missed something
std: Use `read_unaligned` for reads from DWARF
There's a lot of... *stuff* going on here. Meanwhile, `read_unaligned` has been available since 1.17.0, so let's just use that.
Clean up more comments near use declarations
#125443 will reformat all use declarations in the repository. There are a few edge cases involving comments on use declarations that require care. This PR fixes them up so #125443 can go ahead with a simple `x fmt --all`. A follow-up to #126717.
r? ``@cuviper``
Skip fast path for dec2flt when optimize_for_size
Tracking issue: https://github.com/rust-lang/rust/issues/125612
Skip the fast algorithm when optimizing for size.
When compiling for https://github.com/quartiq/stabilizer I get these numbers:
Before
```
text data bss dec hex filename
192192 8 49424 241624 3afd8 dual-iir
```
After
```
text data bss dec hex filename
191632 8 49424 241064 3ada8 dual-iir
```
This saves 560 bytes.
Simplify environment variable examples
I’ve found myself visiting the documentation for `std::env::vars` every few months, and every time I do, it is because I want to quickly get a snippet to print out all environment variables :-)
So I think it could be nice to simplify the examples a little to make them self-contained. It is of course a style question if one should import a module a not, but I personally don’t import modules used just once in a code snippet.
Migrate `compiler-lookup-paths`, `dump-mono-stats` and `prune-link-args` `run-make` tests to `rmake` or `ui` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: dist-x86_64-linux
try-job: armhf-gnu
When we do the big `use` reformatting there are a tiny number of cases
where rustfmt moves a comment from one `use` item to another in an
undesirable way. This commit pre-emptively rearranges things to prevent
this from happening.
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.
