ignore power alignment rule on unions
fixes https://github.com/rust-lang/rust/issues/147348
The power alignment rule only applies to the non-first field of a struct, and so should not apply to unions at all.
The current code also does not consider enums (whose fields might be, morally, structs). Given that C does not actually have ADTs like this it's probably fine from a compatibility perspective, but I'll leave that to the powerpc folks.
cc `@daltenty` `@gilamn5tr`
r? compiler
bootstrap: relax `compiler-rt` root assertion
Not needed during tests. This would otherwise require `src/llvm-project` submodule to be initialized and `compiler-rt/` subdirectory to be present.
I need this and rust-lang/rust#147374 to get bootstrap self-tests to pass with no git submodules checked out locally.
r? `@Kobzol` (or bootstrap)
bootstrap: don't build book redirect pages during dry-run/test
Currently, `./x test bootstrap` does not automatically transitively checkout submodules needed to pass all involved test steps. Apparently one place where bootstrap's self-test can choke on locally is trying to build book redirect pages without the book submodules checked out.
This change is orthogonal to making bootstrap checking out required submodules for self-tests, and IMO is beneficial regardless since IMO we should not be building these redirect pages during test/dry-run _anyway_.
This was blocking me trying to rebless bootstrap self-tests for rust-lang/rust#147372. cf. [#t-infra/bootstrap > Bootstrap self-tests @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20self-tests/near/543157194).
r? `@Kobzol` (or bootstrap)
Set opt-level flag for installing tool only on CI
## Context
ensure_version_or_cargo_install uses -Copt-level=0 for quicker installation. However, the flag affects the tool's performance. For example, typos-cli with opt-level=0 takes 15 seconds for checking /compiler on my local, but the tool with default opt-level only takes less than 1 sec.
It fixesrust-lang/rust#147331
## Changes
This PR enables the option only when the test tidy is run on CI.
We've discussed that opt-level=1 should be enough, so I also change the level from 0 to 1.
cg_llvm: Remove inherent methods from several LLVM FFI types
This is mainly motivated by rust-lang/rust#142897, which proposes to move the LLVM FFI bindings out of `rustc_codegen_llvm` and into `rustc_llvm`, which is arguably the more correct place for them from a linking perspective.
---
In order to perform that migration, all of the types used in FFI signatures also need to be moved. However, several of those types have inherent methods that convert from backend-independent types to LLVM FFI types.
Moving the inherent methods as-is would require adding a lot of otherwise-unnecessary dependencies to `rustc_llvm`. And we can't leave them behind as-is, because inherent methods can't be defined in another crate.
Therefore, this PR replaces several of those inherent methods with either extension trait methods or free functions.
ensure_version_or_cargo_install uses -Copt-level=0 for quicker installation.
However, the flag affects the tool's performance. For example, typos-cli with opt-level=0 takes 15 seconds for checking ./compiler, but the tool with default opt-level only takes less than 1 sec.
This commit enables the option only when the test tidy is run on CI.
update autodiff testcases
unblock https://github.com/EnzymeAD/Enzyme/pull/2430 (again).
Just as I landed a fix for the last test, this one broke. The test should now be fine if the name mangling hash changes again.
Also removed an outdated fixme that's not needed since moving autodiff to an intrinsic. The test currently just checks that it compiles, I'll add more precise checks once we actually run this in CI.
r? compiler
Fix doctest output json
Fixesrust-lang/rust#144798.
Hopefully it will work with the new changes in `libtest` without needing to do both at once.
This PR moves the `rustdoc` merged doctest extra information directly into `libtest` to ensure they share the same rendering to prevent the bug uncovered in rust-lang/rust#144798.
cc `@lolbinary` (as you reviewed the first PR)
And since we're making changes to `libtest`:
r? `@Amanieu`
This will make `-Zbuild-std` automatically build the right crates, notably not building `std` by default, which will both be useful for users and also fix the build for https://does-it-build.noratrieb.dev.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#147288 (compiletest: Make `DirectiveLine` responsible for name/value splitting)
- rust-lang/rust#147309 (Add documentation about unwinding to wasm targets)
- rust-lang/rust#147310 (Mark `PatternTypo` suggestion as maybe incorrect)
- rust-lang/rust#147320 (Avoid to suggest pattern match on the similarly named in fn signature)
- rust-lang/rust#147328 (Implement non-poisoning `Mutex::with_mut`, `RwLock::with` and `RwLock::with_mut`)
- rust-lang/rust#147337 (Make `fmt::Write` a diagnostic item)
- rust-lang/rust#147349 (Improve the advice given by panic_immediate_abort)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve the advice given by panic_immediate_abort
Now that https://github.com/rust-lang/rust/pull/147338 is merged, users should consider using the Cargo support for immediate-aborting panics.
Make `fmt::Write` a diagnostic item
I'm working on an enhancement to [`clippy::format_push_string`](https://rust-lang.github.io/rust-clippy/master/index.html#format_push_string), which would suggest an autofix to replace `push_str`/`+=` with `write!`. But that could require importing `std::fmt::Write`, and so I need this diagnostic item to check if it's already in scope.
The reason I called it `FmtWrite` and not just `Write` is that there's already an `IoWrite` defined.
Mark `PatternTypo` suggestion as maybe incorrect
Partial fix for https://github.com/rust-lang/rust/issues/147303.
`@rustbot` label A-diagnostics A-suggestion-diagnostics D-invalid-suggestion
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
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?
