never_patterns: Parse match arms with no body
Never patterns are meant to signal unreachable cases, and thus don't take bodies:
```rust
let ptr: *const Option<!> = ...;
match *ptr {
None => { foo(); }
Some(!),
}
```
This PR makes rustc accept the above, and enforces that an arm has a body xor is a never pattern. This affects parsing of match arms even with the feature off, so this is delicate. (Plus this is my first non-trivial change to the parser).
~~The last commit is optional; it introduces a bit of churn to allow the new suggestions to be machine-applicable. There may be a better solution? I'm not sure.~~ EDIT: I removed that commit
r? `@compiler-errors`
Resolve associated item bindings by namespace
This is the 3rd commit split off from #118360 with tests reblessed (they no longer contain duplicated diags which were caused by 4c0addc80af4666f26d7ad51fe34a0e2dd0b8b74) & slightly adapted (removed supertraits from a UI test, cc #118040).
> * Resolve all assoc item bindings (type, const, fn (feature `return_type_notation`)) by namespace instead of trying to resolve a type first (in the non-RTN case) and falling back to consts afterwards. This is consistent with RTN. E.g., for `Tr<K = {…}>` we now always try to look up assoc consts (this extends to supertrait bounds). This gets rid of assoc tys shadowing assoc consts in assoc item bindings which is undesirable & inconsistent (types and consts live in different namespaces after all)
> * Consolidate the resolution of assoc {ty, const} bindings and RTN (dedup, better diags for RTN)
> * Fix assoc consts being labeled as assoc *types* in several diagnostics
> * Make a bunch of diagnostics translatable
Fixes#112560 (error → pass).
As discussed
r? `@compiler-errors`
---
**Addendum**: What I call “associated item bindings” are commonly referred to as “type bindings” for historical reasons. Nowadays, “type bindings” include assoc type bindings, assoc const bindings and RTN (return type notation) which is why I prefer not to use this outdated term.
Rollup of 8 pull requests
Successful merges:
- #118505 (Elaborate on ip_addr bit conversion endianness)
- #118581 (OnceLock: Add note about drop and statics)
- #118677 ([rustdoc] Fix display of features)
- #118690 (coverage: Avoid unnecessary macros in unit tests)
- #118693 (Tell MirUsedCollector that the pointer alignment checks calls its panic symbol)
- #118695 (coverage: Merge refined spans in a separate final pass)
- #118709 (fix jobserver GLOBAL_CLIENT_CHECKED uninitialized before use)
- #118722 (rustdoc: remove unused parameter `reversed` from onEach(Lazy))
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: remove unused parameter `reversed` from onEach(Lazy)
This feature was added in edec5807ac to support JavaScript-based toggles that were later replaced with HTML `<details>`.
coverage: Merge refined spans in a separate final pass
Pulling this merge step out of `push_refined_span` and into a separate pass lets us push directly to `refined_spans` instead of calling a helper method.
Because the compiler can now see partial borrows of `refined_spans`, we can remove some extra code that was jumping through hoops to satisfy the borrow checker.
---
``@rustbot`` label +A-code-coverage
Tell MirUsedCollector that the pointer alignment checks calls its panic symbol
Fixes https://github.com/rust-lang/rust/pull/118683 (not an issue, but that PR is a basically a bug report)
When we had `panic_immediate_abort` start adding `#[inline]` to this panic function, builds started breaking because we failed to write up the MIR assert terminator to the correct panic shim. Things happened to work before by pure luck because without this feature enabled, the function we're inserting calls to is `#[inline(never)]` so we always generated code for it.
r? bjorn3
coverage: Avoid unnecessary macros in unit tests
These macros don't provide enough value to justify their complexity, when they can just as easily be functions instead.
---
`@rustbot` label +A-code-coverage
OnceLock: Add note about drop and statics
Hi! Just a minor documentation addition, I've attempted to build docs locally but ran in to issues, so am not 100% sure this change will render correctly.
Elaborate on ip_addr bit conversion endianness
Adds explanation of how endianness is handled when converting `Ipv4Addr` and `Ipv6Addr` to and from bits. This is intended to unblock stabilization of the affected methods.
Addresses #113744
Rollup of 6 pull requests
Successful merges:
- #116420 (discard invalid spans in external blocks)
- #118686 (Only check principal trait ref for object safety)
- #118688 (Add method to get type of an Rvalue in StableMIR)
- #118707 (Ping GuillaumeGomez for changes in rustc_codegen_gcc)
- #118712 (targets: remove not-added {i386,i486}-unknown-linux-gnu)
- #118719 (CFI: Add char to CFI integer normalization)
Failed merges:
- #117586 (Uplift the (new solver) canonicalizer into `rustc_next_trait_solver`)
r? `@ghost`
`@rustbot` modify labels: rollup
targets: remove not-added {i386,i486}-unknown-linux-gnu
These files were added to the repository but never wired up so they could be used - and that was a few years ago without anyone noticing - so let's remove these, they can be re-added if someone wants them.
cc #80662
r? ```@pnkfelix``` (familiar with the tier policy and Wesley is on vacation)
Ping GuillaumeGomez for changes in rustc_codegen_gcc
Since I work on it and also added its testsuite into rustc's CI, I'd like to know if there are changes.
Add method to get type of an Rvalue in StableMIR
Provide a method to StableMIR users to retrieve the type of an Rvalue operation. There were two possible implementation:
1. Create the logic inside stable_mir to process the type according to the Rvalue semantics, which duplicates the logic of `rustc_middle::mir::Rvalue::ty()`.
2. Implement the Rvalue translation from StableMIR back to internal representation, invoke the `rustc_middle::mir::Rvalue::ty()`, and translate the return value to StableMIR.
I chose the first one for now since the duplication was fairly small, and the option 2 would require way more work to translate everything back to rustc internal representation. If we eventually add those translations, we could easily swap to the option 2.
```@compiler-errors``` / ```@ouz-a``` Please let me know if you have any strong opinion here.
r? ```@compiler-errors```
Only check principal trait ref for object safety
It should make things a bit faster, in case we end up registering a bunch of object safety preds.
r? ```@ghost```
discard invalid spans in external blocks
Fixes#116203
This PR has discarded the invalid `const_span`, thereby making the format more neat.
r? ``@Nilstrieb``
Avoid adding builtin functions to `symbols.o`
We found performance regressions in #113923. The problem seems to be that `--gc-sections` does not remove these symbols. I tested that lld removes these symbols, but ld and gold do not.
I found that `used` adds symbols to `symbols.o` at 3e202ead60/compiler/rustc_codegen_ssa/src/back/linker.rs (L1786-L1791).
The PR removes builtin functions.
Note that under LTO, ld still preserves these symbols. (lld will still remove them.)
The first commit also fixes#118559. But I think the second commit also makes sense.
compile-time evaluation: detect writes through immutable pointers
This has two motivations:
- it unblocks https://github.com/rust-lang/rust/pull/116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable"
- it would detect the UB that was uncovered in https://github.com/rust-lang/rust/pull/117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB
When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already.
The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers.
I just hope perf works out.
Fix `rustc_codegen_gcc` build and tests failure in CI
https://github.com/rust-lang/rust/pull/118463 seems to have broke the PR CI, more specificaly the `x86_64-gnu-llvm-16` builder which [fail with](https://github.com/rust-lang/rust/actions/runs/7128709674/job/19411205695?pr=118705#step:26:1668):
```
Building stage1 codegen backend gcc (x86_64-unknown-linux-gnu)
Compiling libc v0.2.147
Compiling rustix v0.38.8
Compiling memchr v2.5.0
Compiling bitflags v2.4.0
Compiling linux-raw-sys v0.4.5
Compiling fastrand v2.0.0
Compiling smallvec v1.10.0
error: invalid `--check-cfg` argument: `values(freebsd10)` (expected `cfg(name, values("value1", "value2", ... "valueN"))`)
error: could not compile `libc` (lib) due to previous error
```
Updating to `libc` version 0.2.150 fixes the build issue since it includes the support for the new check-cfg syntax.
Then it [failed](https://github.com/rust-lang/rust/actions/runs/7129280743/job/19413025132?pr=118706#step:26:2218) with a missing `#![allow(internal_features)]` in one of the example.
r? `@GuillaumeGomez`
These files were added to the repository but never wired up so they could
be used - and that was a few years ago without anyone noticing - so let's
remove these, they can be re-added if someone wants them.
Signed-off-by: David Wood <david@davidtw.co>
Re-enable `rustc_codegen_gcc` tests in CI
When #117947 dropped llvm-15 from CI, we neglected to copy #117313's changes to enable `rustc_codegen_gcc` testing to the new base llvm-16. This is now restored, as well as copying the setup to llvm-17 as well so we hopefully won't miss it next time.
In addition, due to case mismatch in `$extra_env` updates in `docker/run.sh`, I think it wasn't actually getting enabled before, but this should now be fixed. I also avoided the linker hack for `libgccjit.so` that was present before, because that's not needed if the version matches the base `gcc` used for linking.
r? GuillaumeGomez
