Represent diagnostic side effects as dep nodes
This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index.
Some implications of this:
- Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that.
- Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks.
- Reusing a CGU will now emit diagnostics from the task generating it.
Remove existing AFIDT implementation
This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented.
r? oli-obk
Fixes#136286Fixes#137706Fixes#137895
Tracking:
* #133119
Revert: Add *_value methods to proc_macro lib
This reverts https://github.com/rust-lang/rust/pull/136355. That PR caused unexpected breakage:
- the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others
- rustc_lexer can no longer be published to crates.io, which impacts RA
See https://github.com/rust-lang/rust/issues/138647 for context.
Cc `@GuillaumeGomez` `@Amanieu`
coverage: Don't store a body span in `FunctionCoverageInfo`
We aren't using this body span for anything truly essential, and having it around will be awkward when we eventually start to support expansion regions, since they aren't necessarily within the main body.
Remove double nesting in post-merge workflow
See [this](https://github.com/rust-lang/rust/pull/138630#issuecomment-2732224491) :)
Can be tested with:
```bash
#!/bin/bash
PARENT_COMMIT=493c38ba371929579fe136df26eccd9516347c7a
SHA=259fdb521200c9abba547302fc2c826479ef26b2
printf "<details>\n<summary>What is this?</summary>\n" >> output.log
printf "This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.\n" >> output.log
printf "</details>\n\n" >> output.log
cargo run --release post-merge-report ${PARENT_COMMIT} ${SHA} >> output.log
```
I think that it's better to leave the notice in CI, to avoid generating it in citool, which can also be executed locally.
r? `@marcoieni`
Temporarily disable Fuchsia test job to unblock queue
See <https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259> for efforts to fix the test job.
This PR temporarily disables the Fuchsia test job to unblock the queue, so that neither the Fuchsia maintainers nor T-infra maintainers should feel pressured to fix the job ASAP.
Please feel free to re-enable once the test job is fixed.
FYI `@erickt` since you or other Fuchsia maintainers will need to revert this change to merge Fuchsia test job fixes in the future.
r? infra-ci
Add `#[cfg(test)]` for Transition in dfa in `rustc_transmute`
`Transition` is only used in the `Transitions::insert` in test after #137776
Detected by #128637
Extract `for_each_immediate_subpat` from THIR pattern visitors
This is extracted from some larger changes I've been working on, trying to introduce a “THIR pattern id” to refer to THIR pattern nodes without a direct reference.
The future of those changes is somewhat uncertain, due to some [proposed changes involving upvar inference](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/upvar.20inference.20on.20THIR.3F). So I'm taking my preparatory changes that make sense on their own, and extracting them into one or more independent PRs.
---
This particular patch takes two different functions that were both matching on `PatKind` to traverse subpatterns, and extracts the core match into a single helper function.
rustdoc-json: Add tests for `#[repr(...)]`
Works towards #137645 and #81359
Based on #138018, but with only the test changes. CC ```@obi1kenobi```
r? ```@GuillaumeGomez```
Implement `read_buf` for Hermit
Following https://github.com/hermit-os/kernel/pull/1606, it is now safe to implement `Read::read_buf` for file descriptors on Hermit.
cc ```@mkroening```
Leave a breadcrumb towards bootstrap config documentation in `bootstrap.toml`
I was curious as to the possible bootstrap options I can put in config.toml, but had some trouble figuring it out. There is no obvious documentation in `config.toml` (obviously), the documentation in src/bootstrap/defaults is *nice*, but also rather sparse, by design.
I had to dive into the parsing code, and stuble upon [a very helpful doc comment](30f168ef81/src/bootstrap/src/core/config/config.rs (L181)) there to realize that `config.example.toml` *exists*, and that it does, indeed, answer all of my questions.
So I figured it might be worth making this journey a bit easier for future contributors and add mention the `config.example.toml` directly in `config.toml`.
Now, since #137081 is in-flight which would rename `config(.example)?.toml` to `bootstrap(.example)?.toml`, I figure it's better to wait until that one lands, and submit the "new", "correct" filename upfront, instead of landing `config.toml` now and updating it to `boostrap.toml` later.
`@rustbot` blocked #137081
uefi: fs: Implement exists
Also adds the initial file abstractions.
The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol.
After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat.
It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently.
DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators.
This is an effort to break the original PR (https://github.com/rust-lang/rust/pull/129700) into much smaller chunks for faster upstreaming.
Rollup of 7 pull requests
Successful merges:
- #138384 (Move `hir::Item::ident` into `hir::ItemKind`.)
- #138508 (Clarify "owned data" in E0515.md)
- #138531 (Store test diffs in job summaries and improve analysis formatting)
- #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly)
- #138556 (Fix ICE: attempted to remap an already remapped filename)
- #138608 (rustc_target: Add target feature constraints for LoongArch)
- #138619 (Flatten `if`s in `rustc_codegen_ssa`)
r? `@ghost`
`@rustbot` modify labels: rollup
Also adds the initial file abstractions.
The file opening algorithm is inspired from UEFI shell. It starts by
classifying if the Path is Shell mapping, text representation of device
path protocol, or a relative path and converts into an absolute text
representation of device path protocol.
After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the
device path protocol prefix (similar to Windows drive). After that, it
opens the file in the volume using the remaining pat.
It also introduces OwnedDevicePath and BorrowedDevicePath abstractions
to allow working with the base UEFI and Shell device paths efficiently.
DevicePath in UEFI behaves like an a group of nodes laied out in the
memory contiguously and thus can be modeled using iterators.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Mangle rustc_std_internal_symbols functions
This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`.
Helps mitigate https://github.com/rust-lang/rust/issues/104707
try-job: aarch64-gnu-debug
try-job: aarch64-apple
try-job: x86_64-apple-1
try-job: x86_64-mingw-1
try-job: i686-mingw-1
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: test-various
try-job: armhf-gnu
