Add documentation about unwinding to wasm targets
This commit adds some documentation about the state of `-Cpanic=unwind` for the following wasm targets:
* `wasm32-unknown-unknown`
* `wasm32-wasip1`
* `wasm32-wasip2`
* `wasm32v1-none`
Notably it's possible to use `-Cpanic=unwind` with `-Zbuild-std` and it's also mentioned that there are no concrete proposals at this time to adding a new set of targets which support unwinding. My hunch is that in a few years' time it would make sense to enable it by default on these targets (except for `wasm32v1-none`) but that's a problem for future folks to debate. For now this is an attempt to document the status quo.
compiletest: Make `DirectiveLine` responsible for name/value splitting
- Follow-up to rust-lang/rust#147170.
---
Now that all of the directive-parsing functions have access to a `DirectiveLine`, we can move all of the ad-hoc name/value splitting code into `DirectiveLine` itself, making directive parsing simpler and more consistent.
The first commit is just moving code into a submodule, so the actual changes can be seen in the subsequent commits.
r? jieyouxu
This recovers some instruction count regressions after changing most Pat
parsing functions return a non-boxed Pat. It seems to be beneficial to
break out a #[cold] parsing recovery function when the function includes
more parsing, presumably because this requires more stack space and/or
mem copies when LLVM optimizes the wrong path.
First commit treats all constants containing a macro call as non-local
and renames `eval_simple` to be a little clearer.
Second commit removes `CoreConstant` and treats most of them as though
they were local. A couple of the constants like `usize::MAX` are treated
as non-local as different targets may have different values.
`const_is_empty` will now ignore non-local constants since there's no
guarantee that they are the same across all targets/features/versions.
The third commit just changes some `eval` calls to `eval_local`. Most of
these were style lints which shouldn't be assuming the value of a
constant won't ever change.
changelog: none
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?
