clean up checks for constant promotion of integer division/remainder operations
I found the old logic with matches on `Option`s returned by other matches to be kind of complicated, so I rewrote it with `let` chains. There should be no change in behavior.
Implement `set_output_kind` for Emscripten linker
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra RUSTFLAGS. This was previously approved as rust-lang/rust#98358 but there were CI failures that I never got around to fixing.
cc @workingjubilee
Borrowck: Simplify SCC annotation computation, placeholder rewriting
This change backports some changes from the now abandoned rust-lang/rust#142623.
Notably, it simplifies the `PlaceholderReachability` `enum` by replacing the case when no placeholders were reached with a standard `Option::None`.
It also rewrites the API for `scc::Annotations` to be update-mut rather than a more Functional programming style. This showed some slight performance impact in early tests of the PR and definitely makes the implementation simpler.
This probably wants a perf run just for good measure.
r? @lcnr
Do not suggest `derive` if there is already an impl
This PR fixes an issue where the compiler would suggest adding `#[derive(Trait)]` even if the struct or enum already implements that trait manually.
Fixes [#146515](https://github.com/rust-lang/rust/issues/146515)
resolve: Replace `Macros20NormalizedIdent` with `IdentKey`
This is a continuation of https://github.com/rust-lang/rust/pull/150741 and https://github.com/rust-lang/rust/pull/150982 based on the ideas from https://github.com/rust-lang/rust/pull/151491#issuecomment-3784421866.
Before this PR `Macros20NormalizedIdent` was used as a key in various "identifier -> its resolution" maps in `rustc_resolve`.
`Macros20NormalizedIdent` is a newtype around `Ident` in which `SyntaxContext` (packed inside `Span`) is guaranteed to be normalized using `normalize_to_macros_2_0`.
This type is also used in a number of functions looking up identifiers in those maps.
`Macros20NormalizedIdent` still contains span locations, which are useless and ignored during hash map lookups and comparisons due to `Ident`'s special `PartialEq` and `Hash` impls.
This PR replaces `Macros20NormalizedIdent` with a new type called `IdentKey`, which contains only a symbol and a normalized unpacked syntax context. (E.g. `IdentKey` == `Macros20NormalizedIdent` minus span locations.)
So we avoid keeping additional data and doing some syntax context packing/unpacking.
Along with `IdentKey` you can often see `orig_ident_span: Span` being passed around.
This is an unnormalized span of the original `Ident` from which `IdentKey` was obtained.
It is not used in map keys, but it is used in a number of other scenarios:
- diagnostics
- edition checks
- `allow_unstable` checks
This is because `normalize_to_macros_2_0` normalization is lossy and the normalized spans / syntax contexts no longer contain parts of macro backtraces, while the original span contains everything.
compiler: Rename several types/traits for per-query vtables
- Follow-up to https://github.com/rust-lang/rust/pull/151577
---
This is another round of renaming for some subtle types and traits used by the query system, to hopefully make them easier to understand.
Key renames:
- struct `DynamicQuery` → `QueryVTable` (the actual vtable-like structure)
- struct `DynamicQueries` → `PerQueryVTables` (holds a vtable for each query)
- trait `QueryConfig` → `QueryDispatcher`
- (used by generic functions in `rustc_query_system` to interact with query vtables)
- struct `DynamicConfig` → `SemiDynamicQueryDispatcher`
- (implements `QueryDispatcher` by combining a vtable with some compile-time boolean flags for improved perf)
- trait `QueryConfigRestored` → `UnerasedQueryDispatcher`
- (provides a `QueryDispatcher` while also remembering the query's unerased value type; allows some per-query code to be moved out of macros and into generic functions)
This was trickier than `DepKindVTable`, because there are more types and traits involved, and it's harder to come up with distinctive and useful names for all of them.
There should be no change to compiler behaviour.
r? Kivooeo (or compiler)
Add some clarifications and fixes for fmt syntax
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that underscore-prefixed words are just fine. This was changed in https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It referred to a "second argument", but I don't know what second argument it is referring to (which is the first?). Either way, I rewrote the paragraph to try to be a little more explicit, and to use shorter sentences.
- The description of the precision argument wasn't really clear about the distinction of an Nth argument and a named argument. I added a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in https://github.com/rust-lang/reference/pull/2049 to include bare `_`. But fmt named arguments are not allowed to be a bare `_`.
offload: move (un)register lib into global_ctors
Right now we initialize the openmp/offload runtime before every single offload call, and tear it down directly afterwards.
What we should rather do is initialize it once in the binary startup code, and tear it down at the end of the binary execution. Here I implement these changes.
Together, our generated IR has a lot less usage of globals, which in turn simplifies the refactoring in https://github.com/rust-lang/rust/pull/150683, where I introduce a new variant of our offload intrinsic.
r? oli-obk
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra
RUSTFLAGS. This was previously approved as PR 98358 but there were CI failures that I
never got around to fixing.
Don't try to evaluate const blocks during constant promotion
As of https://github.com/rust-lang/rust/pull/138499, trying to evaluate a const block in anything depended on by borrow-checking will result in a query cycle. Since that could happen in constant promotion, this PR adds a check for const blocks there to stop them from being evaluated.
Admittedly, this is a hack. See https://github.com/rust-lang/rust/issues/124328 for discussion of a more principled fix: removing cases like this from constant promotion altogether. To simplify the conditions under which promotion can occur, we probably shouldn't be implicitly promoting division or array indexing at all if possible. That would likely require a FCW and migration period, so I figure we may as well patch up the cycle now and simplify later.
Fixesrust-lang/rust#150464
I'll also lang-nominate this for visibility. I'm not sure there's much to discuss about this PR specifically, but it does represent a change in semantics. In Rust 1.87, the code below compiled. In Rust 1.88, it became a query cycle error. After this PR, it fails to borrow-check because the temporaries can no longer be promoted.
```rust
let (x, y, z);
// We only promote array indexing if the index is known to be in-bounds.
x = &([0][const { 0 }] & 0);
// We only promote integer division if the divisor is known not to be zero.
y = &(1 / const { 1 });
// Furthermore, if the divisor is `-1`, we only promote if the dividend is
// known not to be `int::MIN`.
z = &(const { 1 } / -1);
// The borrowed temporaries can't be promoted, so they were dropped at the ends
// of their respective statements.
(x, y, z);
```
This simplifies the `PlaceholderReachability` `enum` by
replacing the case when no placeholders were reached with
a standard `Option::None`.
It also rewrites the API for `scc::Annotations` to be update-mut
rather than a more Functional programming style. This showed some slight
performance impact in early tests of the PR and definitely makes
the implementation simpler.
Use an associated type default for `Key::Cache`.
They currently aren't used because r-a didn't support them, but r-a support was recently merged in
https://github.com/rust-lang/rust-analyzer/pull/21243.
r? @Noratrieb
Reintroduce `QueryStackFrame` split.
I tried removing it in rust-lang/rust#151203, to replace it with something simpler. But a couple of fuzzing failures have come up and I don't have a clear picture on how to fix them. So I'm reverting the main part of rust-lang/rust#151203.
This commit also adds the two fuzzing tests.
Fixesrust-lang/rust#151226, rust-lang/rust#151358.
r? @oli-obk
lint: Use rustc_apfloat for `overflowing_literals`, add f16 and f128
Switch to parsing float literals for overflow checks using `rustc_apfloat` rather than host floats. This avoids small variations in platform support and makes it possible to start checking `f16` and `f128` as well.
Using APFloat matches what we try to do elsewhere to avoid platform inconsistencies.
Don't expose redundant information in `rustc_public`'s `LayoutShape`
Enum variant layouts don't need to store a full `LayoutShape`; just storing the fields offsets is enough and all other information can be inferred from the parent layout:
- size, align and ABI don't make much sense for individual variants and should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and `variant: VariantShape::Single { .. }`.
In principle, the same refactor could be done on `rustc_abi::Layout` (see [this comment](https://github.com/rust-lang/rust/issues/113988#issuecomment-1646982272)) but I prefer starting with this smaller change first.
Adds two new Tier 3 targets - `aarch64v8r-unknown-none{,-softfloat}`
## New Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`
This PR adds two new Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
These targets are in support of firmware development on upcoming systems using the Arm Cortex-R82, particularly safety-critical firmware development. For now, it can be tested using the Arm's Armv8-R AArch64 Fixed Virtual Platform emulator, which we have used to test this target. We are also in the process of testing this target with the full compiler test suite as part of Ferrocene, in the same way we test `aarch64-unknown-none` to a safety-qualified standard. We have not identified any issues as yet, but if we do, we will send the fixes upstream to you.
## Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
## Tier 3 Policy Notes
To cover off the Tier 3 requirements:
> A tier 3 target must have a designated developer or developers
Arm will maintain this target, and I have presumed the Embedded Devices Working Group will also take an interest, as they maintain the existing Arm bare-metal targets.
> Targets must use naming consistent with any existing targets
We prefix this target with `aarch64` because it generates A64 machine code (like `arm*` generates A32 and `thumb*` generates T32). In an ideal world I'd get to rename the existing target `aarch64v8a-unknown-none` but that's basically impossible at this point. You can assume `v6` for any `arm*` target where unspecified, and you can assume `v8a` for any `aarch64*` target where not specified.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
It works just like the existing AArch64 bare-metal target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate.
It's a bare-metal target, offering libcore and liballoc.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Done
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.
AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Noted.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.
It's AArch64 and so works with LLVM.
checksum-freshness: Fix invalid checksum calculation for binary files
Admittedly this is not the cleanest way to achieve this, but SourceMap is quite intertwined with source files being represented as Strings.
Tracking issue: https://github.com/rust-lang/cargo/issues/14136Closes: rust-lang/rust#151090
Stabilize ppc inline assembly
This stabilizes inline assembly for PowerPC and PowerPC64.
Corresponding reference PR: rust-lang/reference#2056
---
From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335
> Each architecture needs to be reviewed before stabilization:
> * It must have clobber_abi.
Done in https://github.com/rust-lang/rust/pull/146949.
> * It must be possible to clobber every register that is normally clobbered by a function call.
Done in https://github.com/rust-lang/rust/pull/131341
Similarly, `preserves_flags` is also implemented by this PR. Likewise, there is a non-code change to `preserve_flags` expectations that floating point and vector status and sticky bits are preserved. The reference manual update has more details.
> * Generally review that the exposed register classes make sense.
The followings can be used as input/output:
* reg (`r0`, `r[3-12]`, `r[14-r28]`): Any usable general-purpose register
* reg_nonzero (`r[3-12]`, `r[14-r28]`): General-purpose registers, but excludes `r0`. This is needed for instructions which define `r0` to be the value 0, such as register + immediate memory operations.
* reg/reg_nonzero `r29` on PowerPC64 targets.
* freg (`f[0-31]`): 64 bit floating pointer registers
The following are clobber-only:
* `ctr`, `lr`, `xer`: commonly clobbered special-purpose registers used in inline asm
* `cr` (`cr[0-7]`, `cr`): the condition register fields, or the entire condition register.
* `vreg` (`v[0-31]`): altivec/vmx register
* `vsreg` (`vs[0-63]`): vector-scalar register
* `spe_acc`: SPE accumulator, only available for PowerPC SPE targets.
The vreg and vsreg registers technically accept `#[repr(simd)]` types, but require the experimental `altivec` or `vsx` target features to be enabled. That work seems to be tracked here, rust-lang/rust#42743.
The following cannot be used as operands for inline asm:
* `r2`: the TOC pointer, required for most PIC code.
* `r13`: the TLS pointer
* `r[29]`: Reserved for internal usage by LLVM on PowerPC
* `r[30]`: Reserved for internal usage by LLVM on PowerPC and PowerPC64
* `r31`: the frame pointer
* `vrsave`: this is effectively an unused special-purpose register.
The `preserves_flags` behavior is updated with the following behavior (Note, this is not enforceable today due to LLVM restrictions):
* All status and sticky bits of `fpscr`, `spefscr`, and `vscr` are preserved.
The following registers are unavailable:
* `mma[0-7]`: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. If needed, users can mark such clobbers as vsN*4, vsN*4+1,...,vsN*4+3.
* `ap`: This is actually a pseudo-register in gcc/llvm.
* `mq`: This register is only available on Power1 and Power2, and is not supported by llvm.
---
cc @taiki-e
r? @Amanieu
@rustbot label +A-inline-assembly
Switch to parsing float literals for overflow checks using
`rustc_apfloat` rather than host floats. This avoids small variations in
platform support and makes it possible to start checking `f16` and
`f128` as well.
Using APFloat matches what we try to do elsewhere to avoid platform
inconsistencies.
I tried removing it in #151203, to replace it with something simpler.
But a couple of fuzzing failures have come up and I don't have a clear
picture on how to fix them. So I'm reverting the main part of #151203.
This commit also adds the two fuzzing tests.
Fixes#151226, #151358.
Suggest changing `iter`/`into_iter` when the other was meant
When encountering a call to `iter` that should have been `into_iter` and vice-versa, provide a structured suggestion:
```
error[E0271]: type mismatch resolving `<IntoIter<{integer}, 3> as IntoIterator>::Item == &{integer}`
--> $DIR/into_iter-when-iter-was-intended.rs:5:37
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| ----- ^^^^^^^^^^^^^^^^^^^^^ expected `&{integer}`, found integer
| |
| required by a bound introduced by this call
|
note: the method call chain might not have had the expected associated types
--> $DIR/into_iter-when-iter-was-intended.rs:5:47
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| --------- ^^^^^^^^^^^ `IntoIterator::Item` is `{integer}` here
| |
| this expression has type `[{integer}; 3]`
note: required by a bound in `std::iter::Iterator::chain`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider not consuming the `[{integer}, 3]` to construct the `Iterator`
|
LL - let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
LL + let _a = [0, 1, 2].iter().chain([3, 4, 5].iter());
|
```
Finish addressing the original case in rust-lang/rust#68095. Only the case of chaining a `Vec` or `[]` is left unhandled.
Remove uses of `&mut CmResolver`
Before rust-lang/rust#148329, using CmResolver in closures was not possible when trying to reborrow. This pr changes uses of `&mut CmResolver` into a bare `CmResolver`, to keep the code clean (and to not have `&mut &mut Resolver`)
r? @petrochenkov
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
