rustc_target: ppc64 target string fixes for LLVM 20
LLVM continues to clean these up, and we continue to make this consistent. This is similar to 9caced7bad, e985396145, and
a10e744faf.
```@rustbot``` label: +llvm-main
Add the `power8-crypto` target feature
Add the `power8-crypto` target feature. This will enable adding some new PPC intrinsics in stdarch (specifically AES, SHA and CLMUL intrinsics). The implied target feature is from [here](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/PowerPC/PPC.td)
```@rustbot``` label A-target-feature O-PowerPC
bootstrap: Forward cargo JSON output to stdout, not stderr
This fixes the RA errors I've been seeing on proc-macros after the re-landing of #134040.
r? clubby789
Don't use `AsyncFnOnce::CallOnceFuture` bounds for signature deduction
We shouldn't be using `AsyncFnOnce::CallOnceFuture` projection bounds to deduce anything about the return type of an async closure, **only** `AsyncFnOnce::Output`. This was accidental b/c all we were looking at was the def id of the trait, rather than the projection. This PR fixes that.
This doesn't affect stable code, since `CallOnceFuture` bounds cannot be written on stable.
Fixes#134015
Make `Copy` unsafe to implement for ADTs with `unsafe` fields
As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block.
For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields.
Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`.
This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields.
Tracking: #132922
r? ```@compiler-errors```
[AIX] Remove option "-n" from AIX "ln" command
The option `-n` for the AIX `ln` command has a different purpose than it does on Linux. On Linux, the `-n` option is used to treat the destination path as normal file if it is a symbolic link to a directory, which is the default behavior of the AIX `ln` command.
[AIX] Replace sa_sigaction with sa_union.__su_sigaction for AIX
On AIX, the `sa_sigaction` member of `struct sigaction` is accessed as the union member `sa_union.__su_sigaction`.
[AIX] Pass -bnoipath when adding rust upstream dynamic crates
Unlike ELF linkers, AIX doesn't feature `DT_SONAME` to override
the dependency name when outputing a shared library, which is something
we rely on for dylib crates.
See for reference:
bc145cec45/compiler/rustc_codegen_ssa/src/back/linker.rs (L464))
Thus, `ld` on AIX will use the full path to shared libraries as the dependency if passed it
by default unless `noipath` is passed, so pass it here so we don't end up with full path dependencies
for dylib crates.
jsondocck: Parse, don't validate commands.
Centralizes knowledge of jsondocck syntax into the parser, so the checker doesn't need to know what the indexes are.
[Vaguely related zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/jsondocck.20rewrite)
I'm very happy this is negative LoC, despite adding a big, documented enum!
r? ``@fmease``
LLVM continues to clean these up, and we continue to make this
consistent. This is similar to 9caced7bad,
e985396145, and
a10e744faf.
`@rustbot` label: +llvm-main
Rollup of 10 pull requests
Successful merges:
- #131558 (Lint on combining `#[no_mangle]` and `#[export_name]`)
- #133184 (wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next)
- #133456 (Add licenses + Run `cargo update`)
- #133472 (Run TLS destructors for wasm32-wasip1-threads)
- #133853 (use vendor sources by default on dist tarballs)
- #133946 (coverage: Prefer to visit nodes whose predecessors have been visited)
- #134010 (fix ICE on type error in promoted)
- #134029 (coverage: Use a query to find counters/expressions that must be zero)
- #134071 (Configure renovatebot)
- #134102 (Miscellaneous fixes for nix-dev-shell)
r? `@ghost`
`@rustbot` modify labels: rollup
Miscellaneous fixes for nix-dev-shell
this makes it so files in `src/nix-dev-shell` are *not* ignored, as they
should not be. note that `flake.lock` is still ignored globally.
r? `@Noratrieb`
See individual commits for more info.
cc #131176 (it added gitignore entries I'm changing).
Configure renovatebot
This PR adds a basic Renovatebot configuration. We would mostly like to use the bot for updating lockfiles. First, I want to try out if the built-in lockFileMaintenance will work for that. I'm a bit skeptical, because it is not very configurable, but it's worth a try. I set the schedule for Tuesday, so that we can test what happens tomorrow.
I also enabled the dependency dashboard, as I think it could be useful for us, to see a global state of our dependencies.
r? ```@MarcoIeni```
coverage: Use a query to find counters/expressions that must be zero
As of #133446, this query (`coverage_ids_info`) determines which counter/expression IDs are unused. So with only a little extra work, we can take the code that was using that information to determine which coverage counters/expressions must be zero, and move that inside the query as well.
There should be no change in compiler output.
fix ICE on type error in promoted
Fixes https://github.com/rust-lang/rust/issues/133968
Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
coverage: Prefer to visit nodes whose predecessors have been visited
In coverage instrumentation, we need to traverse the control-flow graph and decide what kind of counter (physical counter or counter-expression) should be used for each node that needs a counter.
The existing traversal order is complex and hard to tweak. This new traversal order tries to be a bit more principled, by always preferring to visit nodes whose predecessors have already been visited, which is a good match for how the counter-creation code ends up dealing with a node's in-edges and out-edges.
For several of the coverage tests, this ends up being a strict improvement in reducing the size of the coverage metadata, and also reducing the number of physical counters needed.
(The new traversal should hopefully also allow some further code simplifications in the future.)
---
This is made possible by the separate simplification pass introduced by #133849. Without that, almost any change to the traversal order ends up increasing the size of the expression table or the number of physical counters.
use vendor sources by default on dist tarballs
Tarball sources are distributed with vendor sources along with the `.cargo/config.toml` file configured for vendor sources. This means we can use vendor sources by default unless explicitly disabled with `build.vendor=false` by the user. So, let's do that.
Run TLS destructors for wasm32-wasip1-threads
The target wasm32-wasip1-threads has support for pthreads and allows registration of TLS destructors.
For spawned threads, this registers Rust TLS destructors by creating a pthreads key with an attached destructor function.
For the main thread, this registers an `atexit` handler to run the TLS destructors.
try-job: test-various
wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next
When upgrading [Zed](https://github.com/zed-industries/zed/pull/19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773844
As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773844 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82.
This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
Lint on combining `#[no_mangle]` and `#[export_name]`
This is my very first contribution to the compiler, even though I read the [chapter about lints](https://rustc-dev-guide.rust-lang.org/diagnostics.html) I'm not very certain that this ~~new lint is done right as a builtin lint~~ PR is right. I appreciate any guidance on how to improve the code.
- Add test for issue #47446
- ~~Implement the new lint `mixed_export_name_and_no_mangle` as a builtin lint (not sure if that is the right way to go)~~ Extend `unused_attributes` lint
- Add suggestion how to fix it
<details>
<summary>Old proposed new lint</summary>
> The `mixed_export_name_and_no_mangle` lint detects usage of both `#[export_name]` and `#[no_mangle]` on the same item which results on `#[no_mangle]` being ignored.
>
> *warn-by-default*
>
> ### Example
>
> ```rust
> #[no_mangle] // ignored
> #[export_name = "foo"] // takes precedences
> pub fn bar() {}
> ```
>
> ### Explanation
>
> The compiler will not respect the `#[no_mangle]` attribute when generating the symbol name for the function, as the `#[export_name]` attribute takes precedence. This can lead to confusion and is unnecessary.
</details>
CI: move `dist-arm-linux` to an ARM runner
First, I want to test whether we could actually move this to a free runner, vs moving to the 8-core ARM runner.
Fixes: https://github.com/rust-lang/infra-team/issues/181
r? `@MarcoIeni`
try-job: dist-arm-linux
Introduce `default_field_values` feature
Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681.
We now parse const expressions after a `=` in a field definition, to specify a `struct` field default value.
We now allow `Struct { field, .. }` where there's no base after `..`.
`#[derive(Default)]` now uses the default value if present, continuing to use `Default::default()` if not.
```rust
#[derive(Debug)]
pub struct S;
#[derive(Debug, Default)]
pub struct Foo {
pub bar: S = S,
pub baz: i32 = 42 + 3,
}
fn main () {
let x = Foo { .. };
let y = Foo::default();
let z = Foo { baz: 1, .. };
assert_eq!(45, x.baz);
assert_eq!(45, y.baz);
assert_eq!(1, z.baz);
}
```
`libz.so.1` is needed for some (?) things...
i personally found myself in need of it when running `x t linkchecker`,
which failed when running cargo build script or something.
although there are also mentions of rustc itself needing it:
<https://github.com/NixOS/nixpkgs/issues/92946>
