Make opaque types regular HIR nodes
Having opaque types as HIR owner introduces all sorts of complications. This PR proposes to make them regular HIR nodes instead.
I haven't gone through all the test changes yet, so there may be a few surprises.
Many thanks to `@camelid` for the first draft.
Fixes https://github.com/rust-lang/rust/issues/129023Fixes#129099Fixes#125843Fixes#119716Fixes#121422
Update cargo
17 commits in 80d82ca22abbee5fb7b51fa1abeb1ae34e99e88a..ad074abe3a18ce8444c06f962ceecfd056acfc73
2024-09-27 17:56:01 +0000 to 2024-10-04 18:18:15 +0000
- test: Remove the last of our custom json assertions (rust-lang/cargo#14576)
- docs(ref): Expand on MSRV (rust-lang/cargo#14636)
- docs: Minor re-grouping of pages (rust-lang/cargo#14620)
- docs(ref): Highleft whats left for msrv-policy (rust-lang/cargo#14638)
- Fix `cargo:version_number` - has only one `:` (rust-lang/cargo#14637)
- docs: Declare support level for each crate in our Charter / docs (rust-lang/cargo#14600)
- chore(deps): update tar to 0.4.42 (rust-lang/cargo#14632)
- docs(charter): Declare new Intentional Artifacts as 'small' changes (rust-lang/cargo#14599)
- fix: Remove implicit feature removal (rust-lang/cargo#14630)
- docs(config): make `--config <PATH>` more prominent (rust-lang/cargo#14631)
- chore(deps): update rust crate unicode-width to 0.2.0 (rust-lang/cargo#14624)
- chore(deps): update embarkstudios/cargo-deny-action action to v2 (rust-lang/cargo#14628)
- docs(ref): Clean up language for `package.rust-version` (rust-lang/cargo#14619)
- docs: clarify `target.'cfg(...)'` doesnt respect cfg from build script (rust-lang/cargo#14312)
- test: relax compiler panic assertions (rust-lang/cargo#14618)
- refactor(compiler): zero-copy deserialization when possible (rust-lang/cargo#14608)
- test: add support for features in the sat resolver (rust-lang/cargo#14583)
Stabilize the `map`/`value` methods on `ControlFlow`
And fix the stability attribute on the `pub use` in `core::ops`.
libs-api in https://github.com/rust-lang/rust/issues/75744#issuecomment-2231214910 seemed reasonably happy with naming for these, so let's try for an FCP.
Summary:
```rust
impl<B, C> ControlFlow<B, C> {
pub fn break_value(self) -> Option<B>;
pub fn map_break<T>(self, f: impl FnOnce(B) -> T) -> ControlFlow<T, C>;
pub fn continue_value(self) -> Option<C>;
pub fn map_continue<T>(self, f: impl FnOnce(C) -> T) -> ControlFlow<B, T>;
}
```
Resolves#75744
``@rustbot`` label +needs-fcp +t-libs-api -t-libs
---
Aside, in case it keeps someone else from going down the same dead end: I looked at the `{break,continue}_value` methods and tried to make them `const` as part of this, but that's disallowed because of not having `const Drop`, so put it back to not even unstably-const.
Add x86_64-unknown-trusty as tier 3 target
This PR adds a third target for the Trusty platform, `x86_64-unknown-trusty`.
Please let me know if an MCP is required. https://github.com/rust-lang/compiler-team/issues/582 was made when adding the first two targets, I can make another one for the new target as well if needed.
# Target Tier Policy Acknowledgements
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
- Nicole LeGare (```@randomPoison)```
- Andrei Homescu (```@ahomescu)```
- Chris Wailes (chriswailes@google.com)
- As a fallback trusty-dev-team@google.com can be contacted
Note that this does not reflect the maintainers currently listed in [`trusty.md`](https://github.com/rust-lang/rust/blob/c52c23b6f44cd19718721a5e3b2eeb169e9c96ff/src/doc/rustc/src/platform-support/trusty.md). #130452 is currently open to update the list of maintainers in the documentation.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
The new target `x86_64-unknown-trusty` follows the existing naming convention for similar targets.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
👍
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
There are no known legal issues or license incompatibilities.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
👍
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
This PR only adds the target. `std` support is being worked on and will be added in a future PR.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
👍
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ```@)``` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
👍
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
👍
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
👍
Enable `--no-sandbox` option by default for rustdoc GUI tests
It's apparently common enough for people to have issues with the `sandbox` mode in chromium, so better disable it by default.
r? `@notriddle`
Implement RFC3695 Allow boolean literals as cfg predicates
This PR implements https://github.com/rust-lang/rfcs/pull/3695: allow boolean literals as cfg predicates, i.e. `cfg(true)` and `cfg(false)`.
r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
Refactoring to `OpaqueTyOrigin`
Pulled out of a larger PR that uses these changes to do cross-crate encoding of opaque origin, so we can use them for edition 2024 migrations. These changes should be self-explanatory on their own, tho 😄
Rollup of 3 pull requests
Successful merges:
- #126930 (Add unstable support for outputting file checksums for use in cargo)
- #130725 (Parser: better error messages for ``@`` in struct patterns)
- #131166 (Fix `target_vendor` for `aarch64-nintendo-switch-freestanding`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add unstable support for outputting file checksums for use in cargo
Adds an unstable option that appends file checksums and expected lengths to the end of the dep-info file such that `cargo` can read and use these values as an alternative to file mtimes.
This PR powers the changes made in this cargo PR https://github.com/rust-lang/cargo/pull/14137
Here's the tracking issue for the cargo feature https://github.com/rust-lang/cargo/issues/14136.
std: make `thread::current` available in all `thread_local!` destructors
... and thereby allow the panic runtime to always print the right thread name.
This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by `std` have run. Unfortunately, this doesn't affect foreign TLS destructors, `thread::current` will still panic there.
Additionally, the thread ID returned by `current_id` will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS).
The mechanisms I added for this (`local_pointer` and `thread_cleanup`) will also allow finally fixing #111272 by moving the signal stack to a similar runtime-cleanup TLS variable.
[CI] Upload average CPU utilization of CI jobs to DataDog
This PR adds a new CI step that uploads the average CPU utilization of the current GH job to Datadog. I want to add more metrics in follow-up PRs.
r? `@jdno`
try-job: dist-i686-msvc
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
Update helper docs display disable option
Updated helper docs via configure.py to make it clearer that users can control options with enable and disable
Fixing issue #129146
Revert #131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags"
In [#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for
(at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc
--print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe.
This PR reverts 5a7058c5a5 (reverts PR #131060) in favor of a future
fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the
`-Zon-broken-pipe=kill` flag for rustc binary builds.
I could not figure out how to write a regression test for the `rustc --print=sysroot | false`
behavior on Unix, so this is a plain revert for now.
This revert will unfortunately reintroduce #130980 until we fix it again with the different approach.
See more details at <https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033> and in the timeline below.
### Timeline of kill-process-on-broken-pipe behavior changes
See [`unix_sigpipe` tracking issue #97889][#97889] for more context around unix sigpipe handling.
- From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if
output pipe is broken yet the program tries to use `println!` and such, there will be a broken
pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [#34376].
- [#49606] mitigated [#34376] by adding an explicit signal handler to `rustc_driver` register a
sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if
`rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses
`rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`.
- A more universal way to set sigpipe behavior for Unix was introduced as part of [#97889], i.e. `#
[unix_sigpipe = "sig_dfl"]` attribute.
- [#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of
`rustc_driver::set_sigpipe_handler`.
- [#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of
`rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed.
- Following concerns about sigpipe setting UI in [#97889], the UI for specifying sigpipe behavior
was changed in [#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag
`-Zon-broken-pipe=kill`.
- In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main
binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe
behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and
`rustc` during compile steps.
- [#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri
tests because at the time the PR was written, this would lead to a couple of cargo test failures.
Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo`
without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool
build cache. This is not a problem at the time, because nothing (not even miri) tests built stage
1 cargo (all used initial cargo).
- In [#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not
just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but
absent in beta cargo, which was blocking a beta backport.
- [#130642] and later [#130739] now build stage 1 cargo. And as previously mentioned, since
`-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache
invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing
`RUSTFLAGS` since `run-make` also builds `rustdoc` and such [#130980].
[#34376]: https://github.com/rust-lang/rust/issues/34376
[#49606]: https://github.com/rust-lang/rust/pull/49606
[#97889]: https://github.com/rust-lang/rust/issues/97889
[#102587]: https://github.com/rust-lang/rust/pull/102587
[#103495]: https://github.com/rust-lang/rust/pull/103495
[#124480]: https://github.com/rust-lang/rust/pull/124480
[#130634]: https://github.com/rust-lang/rust/issues/130634
[#130642]: https://github.com/rust-lang/rust/pull/130642
[#130739]: https://github.com/rust-lang/rust/pull/130739
[#130980]: https://github.com/rust-lang/rust/issues/130980
[#131059]: https://github.com/rust-lang/rust/issues/131059
[^1]: https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033
r? ``@onur-ozkan`` (or bootstrap)
panic when an interpreter error gets unintentionally discarded
One important invariant of Miri is that when an interpreter error is raised (*in particular* a UB error), those must not be discarded: it's not okay to just check `foo().is_err()` and then continue executing.
This seems to catch new contributors by surprise fairly regularly, so this PR tries to make it so that *if* this ever happens, we get a panic rather than a silent missed UB bug. The interpreter error type now contains a "guard" that panics on drop, and that is explicitly passed to `mem::forget` when an error is deliberately discarded.
Fixes https://github.com/rust-lang/miri/issues/3855
Update wasm-component-ld to 0.5.9
This updates the `wasm-component-ld` linker binary for the `wasm32-wasip2` target to 0.5.9, pulling in a few bug fixes and recent updates.
rustdoc: rewrite stability inheritance as a doc pass
Since doc inlining can almost arbitrarily change the module hierarchy, we can't just use the HIR ancestors of an item to compute its effective stability. This PR moves the stability inheritance that I implemented in https://github.com/rust-lang/rust/pull/130798 into a new doc pass `propagate-stability` that runs after doc inlining and uses the post-inlining ancestors of an item to correctly compute its effective stability.
fixes https://github.com/rust-lang/rust/issues/131020
r? `@notriddle`
Henri Lunnikivi