bless autodiff batching test
This pr blesses a broken test and unblocks running rust in the Enzyme CI: https://github.com/EnzymeAD/Enzyme/pull/2430
Enzyme is the plugin used by our std::autodiff and (future) std::batching modules, both of which are not build by default.
In the near future we also hope to enable std::autodiff in the Rust CI.
This test is the only one to combine two features, automatic differentiation and batching/vectorization. This combination is even more experimental than either feature on its own. I have a wip branch in which I enable more vectorization/batching and as part of that I'll think more about how to write those tests in a robust way (and likely change the interface). Until that lands, I don't care too much about what specific IR we generate here; it's just nice to track changes.
r? compiler
Return to needs-llvm-components being info-only
Partially revert a535042e80
Even with non-LLVM codegen backends, we want to allow for annotations that express dependencies to LLVM-specific parts of the test suite. This includes `//@ needs-llvm-components`, which just allows checking that LLVM is built with relevant target support before the test is run. It does not assert the test cannot work with another codegen backend.
Do not assert that a change in global cache only happens when concurrent
Fixesrust-lang/trait-system-refactor-initiative#234
I think it should just be safe to remove this assert (rather than delaying a bug). If the previous and current result are the same, I wouldn't expect issues.
r? lcnr
std: `sys::net` cleanups
This PR contains three improvements to the socket-based networking implementation (aa1263e768 is just to add the now missing `unsafe`). Best reviewed commit-by-commit.
interpret `#[used]` as `#[used(compiler)]` on illumos
helps rust-lang/rust#146169 not be as painful: fixes the illumos regression in rust-lang/rust#140872, but `#[used(linker)]` is still erroneous on illumos generally.
illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would.
As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed.
Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance.
----
as it turns out, `tests/ui/attributes/used_with_archive.rs` had broken on `x86_64-unknown-illumos`, and this patch fixes it. the trials and tribulations of tier 2 :(
r? ````@Noratrieb```` probably?
Fix top level ui tests check in tidy
I got an error when pushing code:
```console
fmt check
fmt: checked 6330 modified files
tidy check
tidy [ui_tests (tests)]: ui tests should be added under meaningful subdirectories: `/Users/yukang/rust/tests/ui/.DS_Store`
tidy [ui_tests (tests)]: FAIL
```
I think it's better to use `ignore::WalkBuilder` for checking the path.
r? `@jieyouxu`
Don't normalize higher-ranked assumptions if they're not used
See the comment in the code.
Normalizing these assumptions may cause us to register things like new placeholder outlives obligations that cause higher-ranked lifetime errors, and this is problematic if we're not even using these assumptions in borrowck.
Fixesrust-lang/rust#147244Fixesrust-lang/rust#147285
illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or
SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]`
for that target. Setting `USED_LINKER` to try results in LLVM setting
SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section
header flag for illumos `ld` and prevents sections from being merged
that otherwise would.
As a motivating example, the `inventory` crate produces
`#[used]` items to merge into `.init_array`. Because those items have an
unknown section header flag they are not merged with the default
`.init_array` with `frame_dummy`, and end up never executed.
Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps
so-attributed items as preserved as they had been before
https://github.com/rust-lang/rust/pull/140872. As was the case before
that change, because rustc passes `-z ignore` to illumos `ld`, it's
possible that `used` sections are GC'd at link time.
https://github.com/rust-lang/rust/issues/146169 describes this
unfortunate circumstance.
Respect `-Z` unstable options in `rustdoc --test`
This PR makes rustdoc respect `-Z` unstable options when collecting doctests (`rustdoc --test`).
In the process I also realized that `--error-format` wasn't respected as well, making UI annotations impossible to write so I fixed that as well.
Best reviewed commit by commit.
Fixes https://github.com/rust-lang/rust/issues/147276
Fixes https://github.com/rust-lang/rust/issues/143930
r? fmease
only replace the intended comma in pattern suggestions
Only suggest to replace the intended comma, not all bars in the pattern.
Fixesrust-lang/rust#143330.
This continues rust-lang/rust#143331, the credit for making the fix goes to `@A4-Tacks.` I just blessed tests and added a regression test.
Fix backtraces with `-C panic=abort` on linux; emit unwind tables by default
The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work.
Closes https://github.com/rust-lang/rust/issues/81902 which is **regression-from-stable-to-stable**
Closes https://github.com/rust-lang/rust/issues/94815
### History
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see https://github.com/rust-lang/rust/pull/45031 and https://github.com/rust-lang/rust/issues/81902#issuecomment-3046487084).
In 1.45 a workaround in the form of `-C force-unwind-tables=yes` was added (see https://github.com/rust-lang/rust/pull/69984).
`-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact.
# Release Note Entry Draft:
## Compatibility Notes
* [Fix backtraces with `-C panic=abort` on Linux by generating unwind tables by default](https://github.com/rust-lang/rust/pull/143613). Build with `-C force-unwind-tables=no` to keep omitting unwind tables.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: aarch64-msvc-1
Introduce debuginfo to statements in MIR
The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix rust-lang/rust#128081.
I don't modify Stable MIR, as I don't think we need debug information when using it.
This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv.
The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.
The current rules for dropping debug information in this PR are:
- If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
- All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.
I doesn't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#141839 (make rust-analyzer use a dedicated build directory)
- rust-lang/rust#146166 (Implement range support in `//@ edition`)
- rust-lang/rust#147259 (cg_llvm: Use helper methods for all calls to `LLVMMDNodeInContext2`)
- rust-lang/rust#147263 (Disable triagebot auto stable-regression compiler backport nominations pending redesign)
- rust-lang/rust#147268 (add arm-maintainers to various targets)
- rust-lang/rust#147270 (Move doc_cfg-specific code into `cfg.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
If the `LocalRef` is `LocalRef::Place`, we can refer to it directly,
because the local of place is an indirect pointer.
Such a statement is `_1 = &(_2.1)`.
If the `LocalRef` is `LocalRef::Operand`,
the `OperandRef` should provide the pointer of the reference.
Such a statement is `_1 = &((*_2).1)`.
But there is a special case that hasn't been handled, scalar pairs like `(&[i32; 16], i32)`.
add arm-maintainers to various targets
Add the ``@rust-lang/arm-maintainers`` team as maintainers to the following targets:
- `aarch64-unknown-linux-gnu`
- `aarch64-unknown-none`/`aarch64-unknown-none-softfloat`
- `aarch64-unknown-uefi`
- `armv7-unknown-linux-gnueabi`/`armv7-unknown-linux-gnueabihf`
- `armv7a-none-eabi`/`armv7a-none-eabihf`
- `armv7r-none-eabi`/`armv7r-none-abihf`
- `armv8r-none-eabihf`
- `thumbv7em-none-eabi`/`thumbv7em-none-eabihf`
- `thumbv7m-none-eabi`
- `thumbv8m.base-none-eabi`
- `thumbv8m.main-none-eabi`/`thumbv8m.main-none-eabihf`
cc `@thejpster`
Disable triagebot auto stable-regression compiler backport nominations pending redesign
Current auto compiler stable-regression backport nominations seem to be too aggressive, and seems to unfortunately lower signal-to-noise ratio of the compiler backport channel. So this PR disables the triagebot compiler auto stable-regression backport nominations pending a redesign. Beta-regression auto backport nominations are not modified, we might want to gather some more experience with it.
No prejudice against re-enabling them if the nominations include a bit more context on _why_ it's automatically nominated and _which_ regression(s) are being addressed. Or as proposed, it could also simply become a reminder-to-nominate _comment_.
cf. [#t-compiler/backports > #146919: stable-nominated @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports/topic/.23146919.3A.20stable-nominated/near/540979327)
> I like the idea of rustbot just posting a message that suggests adding the label. That seems like a good compromise between avoiding forgotten nominations and avoiding spurious nominations.
In any case, this was very much worth experimenting!
r? `@apiraino` (or triagebot)
cg_llvm: Use helper methods for all calls to `LLVMMDNodeInContext2`
Originally I was only planning on extracting an `md_node_in_context` method, but then I noticed that all callers of `LLVMMDNodeInContext2` could be covered by a small number of additional helper methods.
There should be no change in compiler output.
Extending `#[rustc_force_inline]` to be applicable to inherent methods
`#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved).
`#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions).
Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined.
r? `@saethlin`
Partially revert a535042e80
Even with non-LLVM codegen backends, we want to allow for annotations
that express dependencies to LLVM-specific parts of the test suite.
This includes `//@ needs-llvm-components`, which just allows checking
that LLVM is built with relevant target support before the test is run.
It does not assert the test cannot work with another codegen backend.
