make `typeid::typeid_itanium_cxx_abi::transform_ty` evaluate length in array types
the ICE in https://github.com/rust-lang/rust/issues/114275 was caused by `transform_ty`
in compiler/rustc_symbol_mangling/src/typeid/typeid_itanium_cxx_abi.rs encountering an unevaluated const, while expecting it to already be evaluated.
Rollup of 7 pull requests
Successful merges:
- #114599 (Add impl trait declarations to SMIR)
- #114622 (rustc: Move `crate_types` and `stable_crate_id` from `Session` to `GlobalCtxt`)
- #114662 (Unlock trailing where-clauses for lazy type aliases)
- #114693 (Remove myself from the review rotation)
- #114694 (make the provisional cache slightly less broken)
- #114705 (Add spastorino to mailmap)
- #114712 (Fix a couple of bad comments)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix a couple of bad comments
A couple of nits I saw. Sorry, this really should be folded into some other PR of mine, but I will literally forget if I don't put these up now.
make the provisional cache slightly less broken
It is still broken for the following cycles:
```mermaid
graph LR
R["R: coinductive"] --> A["A: inductive"]
R --> B["B: coinductive"]
A --> B
B --> R
```
the `R -> A -> B -> R` cycle should be considered to not hold, as it is mixed, but because we first put `B` into the cache from the `R -> B -> R` cycle which is coinductive, it does hold.
This issue will also affect our new coinduction approach. Longterm cycles are coinductive as long as one step goes through an impl where-clause, see f4fc5bae36/crates/formality-prove/src/prove/prove_wc.rs (L51-L62). Here we would first have a fully inductive cycle `R -> B -> R` which is then entered by a cycle with a coinductive step `R -> A -coinductive-> B -> R`.
I don't know how to soundly implement a provisional cache for goals not on the stack without tracking all cycles the goal was involved in and whether they were inductive or not. We could then only use goals from the cache if the *inductivity?* of every cycle remained the same. This is a mess to implement. I therefore want to rip out the provisional cache entirely, but will wait with this until I talked about it with `@nikomatsakis.`
r? `@compiler-errors`
Unlock trailing where-clauses for lazy type aliases
Allows trailing where-clauses on lazy type aliases and forbids[^1] leading ones.
Completes #89122 (see section *Top-level type aliases*).
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
[^1]: This is absolutely fine since lazy type aliases are only meant to be stabilized as part of a new edition.
coverage: Don't convert filename/symbol strings to `CString` for FFI
LLVM APIs are usually perfectly happy to accept pointer/length strings, as long as we supply a suitable length value when creating a `StringRef` or `std::string`.
This lets us avoid quite a few intermediate `CString` copies during coverage codegen. It also lets us use an `IndexSet<Symbol>` (instead of an `IndexSet<CString>`) when building the deduplicated filename table.
Remove redundant calls to `resolve_vars_with_obligations`
I've been auditing the calls to `resolve_vars_with_obligations` for the new solver, and have found a few that have no effect on diagnostics. Let's just remove 'em.
Also remove a redundant `resolve_vars_with_obligations_and_mutate_fulfillment` call.
r? ``@lcnr``
`Expr::can_have_side_effects()` is incorrect for struct/enum/array/tuple literals
It would return 'false' unless *all* sub-expressions had side effects. This would easily allow side effects to slip through, and also wrongly label empty literals as having side effects. Add some tests for the last point
The function is only used for simple lints and error messages, so not a serious bug.
this ICE was caused by `transform_ty`
in compiler/rustc_symbol_mangling/src/typeid/typeid_itanium_cxx_abi.rs
encountering an unevaluated const, while expecting it to already be evaluated.
add a regression test
Update tests/ui/sanitize/issue-114275-cfi-const-expr-in-arry-len.rs
Co-authored-by: Michael Goulet <michael@errs.io>
Update tests/ui/sanitize/issue-114275-cfi-const-expr-in-arry-len.rs
Co-authored-by: Michael Goulet <michael@errs.io>
fix test compiling for targets with -crt-static and failing
this was causign https://github.com/rust-lang/rust/pull/114686 to fail
Rollup of 6 pull requests
Successful merges:
- #110435 (rustdoc-json: Add test for field ordering.)
- #111891 (feat: `riscv-interrupt-{m,s}` calling conventions)
- #114377 (test_get_dbpath_for_term(): handle non-utf8 paths (fix FIXME))
- #114469 (Detect method not found on arbitrary self type with different mutability)
- #114587 (Convert Const to Allocation in smir)
- #114670 (Don't use `type_of` to determine if item has intrinsic shim)
Failed merges:
- #114599 (Add impl trait declarations to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't use `type_of` to determine if item has intrinsic shim
When we're calling `resolve_instance` on an inline const, we were previously looking at the `type_of` for that const, seeing that it was an `extern "intrinsic"` fn def, and treating it as if we were computing the instance of that intrinsic itself. This is incorrect.
Instead, we should be using the def-id of the item we're computing to determine if it's an intrinsic.
Fixes#114660
Detect method not found on arbitrary self type with different mutability
```
error[E0599]: no method named `x` found for struct `Pin<&S>` in the current scope
--> $DIR/arbitrary_self_type_mut_difference.rs:11:18
|
LL | Pin::new(&S).x();
| ^ help: there is a method with a similar name: `y`
|
note: method is available for `Pin<&mut S>`
--> $DIR/arbitrary_self_type_mut_difference.rs:6:5
|
LL | fn x(self: Pin<&mut Self>) {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Related to #57994, as one of the presented cases can lead to code like this.
feat: `riscv-interrupt-{m,s}` calling conventions
Similar to prior support added for the mips430, avr, and x86 targets this change implements the rough equivalent of clang's [`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling e.g.
```rust
static mut CNT: usize = 0;
pub extern "riscv-interrupt-m" fn isr_m() {
unsafe {
CNT += 1;
}
}
```
to produce highly effective assembly like:
```asm
pub extern "riscv-interrupt-m" fn isr_m() {
420003a0: 1141 addi sp,sp,-16
unsafe {
CNT += 1;
420003a2: c62a sw a0,12(sp)
420003a4: c42e sw a1,8(sp)
420003a6: 3fc80537 lui a0,0x3fc80
420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0>
420003ae: 0585 addi a1,a1,1
420003b0: 62b52e23 sw a1,1596(a0)
}
}
420003b4: 4532 lw a0,12(sp)
420003b6: 45a2 lw a1,8(sp)
420003b8: 0141 addi sp,sp,16
420003ba: 30200073 mret
```
(disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`)
This outcome is superior to hand-coded interrupt routines which, lacking visibility into any non-assembly body of the interrupt handler, have to be very conservative and save the [entire CPU state to the stack frame][full-frame-save]. By instead asking LLVM to only save the registers that it uses, we defer the decision to the tool with the best context: it can more accurately account for the cost of spills if it knows that every additional register used is already at the cost of an implicit spill.
At the LLVM level, this is apparently [implemented by] marking every register as "[callee-save]," matching the semantics of an interrupt handler nicely (it has to leave the CPU state just as it found it after its `{m|s}ret`).
This approach is not suitable for every interrupt handler, as it makes no attempt to e.g. save the state in a user-accessible stack frame. For a full discussion of those challenges and tradeoffs, please refer to [the interrupt calling conventions RFC][rfc].
Inside rustc, this implementation differs from prior art because LLVM does not expose the "all-saved" function flavor as a calling convention directly, instead preferring to use an attribute that allows for differentiating between "machine-mode" and "superivsor-mode" interrupts.
Finally, some effort has been made to guide those who may not yet be aware of the differences between machine-mode and supervisor-mode interrupts as to why no `riscv-interrupt` calling convention is exposed through rustc, and similarly for why `riscv-interrupt-u` makes no appearance (as it would complicate future LLVM upgrades).
[clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v
[full-frame-save]: 9281af2ecf/src/lib.rs (L440-L469)
[implemented by]: b7fb2a3fec/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp (L61-L67)
[callee-save]: 973f1fe7a8/llvm/lib/Target/RISCV/RISCVCallingConv.td (L30-L37)
[rfc]: https://github.com/rust-lang/rfcs/pull/3246
fix: not insert missing lifetime for `ConstParamTy`
Fixes#113462
We should ignore the missing lifetime, as it's illegal to include a lifetime in a const param.
r? ``@compiler-errors``
These new interrupt calling conventions are not themselves stabilized,
but there are other unstable calling conventions present in the SMIR
mapping (e.g. AVR interrupts) and the mapping appears to be "complete"
so far, with no obvious way to represent unstable conventions separately
from the stable ones.
Similar to prior support added for the mips430, avr, and x86 targets
this change implements the rough equivalent of clang's
[`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling
e.g.
```rust
static mut CNT: usize = 0;
pub extern "riscv-interrupt-m" fn isr_m() {
unsafe {
CNT += 1;
}
}
```
to produce highly effective assembly like:
```asm
pub extern "riscv-interrupt-m" fn isr_m() {
420003a0: 1141 addi sp,sp,-16
unsafe {
CNT += 1;
420003a2: c62a sw a0,12(sp)
420003a4: c42e sw a1,8(sp)
420003a6: 3fc80537 lui a0,0x3fc80
420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0>
420003ae: 0585 addi a1,a1,1
420003b0: 62b52e23 sw a1,1596(a0)
}
}
420003b4: 4532 lw a0,12(sp)
420003b6: 45a2 lw a1,8(sp)
420003b8: 0141 addi sp,sp,16
420003ba: 30200073 mret
```
(disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`)
This outcome is superior to hand-coded interrupt routines which, lacking
visibility into any non-assembly body of the interrupt handler, have to
be very conservative and save the [entire CPU state to the stack
frame][full-frame-save]. By instead asking LLVM to only save the
registers that it uses, we defer the decision to the tool with the best
context: it can more accurately account for the cost of spills if it
knows that every additional register used is already at the cost of an
implicit spill.
At the LLVM level, this is apparently [implemented by] marking every
register as "[callee-save]," matching the semantics of an interrupt
handler nicely (it has to leave the CPU state just as it found it after
its `{m|s}ret`).
This approach is not suitable for every interrupt handler, as it makes
no attempt to e.g. save the state in a user-accessible stack frame. For
a full discussion of those challenges and tradeoffs, please refer to
[the interrupt calling conventions RFC][rfc].
Inside rustc, this implementation differs from prior art because LLVM
does not expose the "all-saved" function flavor as a calling convention
directly, instead preferring to use an attribute that allows for
differentiating between "machine-mode" and "superivsor-mode" interrupts.
Finally, some effort has been made to guide those who may not yet be
aware of the differences between machine-mode and supervisor-mode
interrupts as to why no `riscv-interrupt` calling convention is exposed
through rustc, and similarly for why `riscv-interrupt-u` makes no
appearance (as it would complicate future LLVM upgrades).
[clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v
[full-frame-save]: 9281af2ecf/src/lib.rs (L440-L469)
[implemented by]: b7fb2a3fec/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp (L61-L67)
[callee-save]: 973f1fe7a8/llvm/lib/Target/RISCV/RISCVCallingConv.td (L30-L37)
[rfc]: https://github.com/rust-lang/rfcs/pull/3246
Restrict linker version script of proc-macro crates to just its two symbols
Restrict linker version script of proc-macro crates to just the two symbols of each proc-macro crate.
The main known effect of doing this is to stop including `#[no_mangle]` symbols in the linker version script.
Background:
The combination of a proc-macro crate with an import of another crate that itself exports a no_mangle function was broken for a period of time, because:
* In PR #99944 we stopped exporting no_mangle symbols from proc-macro crates; proc-macro crates have a very limited interface and are meant to be treated as a blackbox to everything except rustc itself. However: he constructed linker version script still referred to them, but resolving that discrepancy was left as a FIXME in the code, tagged with issue #99978.
* In PR #108017 we started telling the linker to check (via the`--no-undefined-version` linker invocation flag) that every symbol referenced in the "linker version script" is provided as linker input. So the unresolved discrepancy from #99978 started surfacing as a compile-time error (e.g. #111888).
Fix#111888Fix#99978.
Allowing re-implementation of mir_drops_elaborated query
For our use case of the rust compiler interface (a rust verifier called [Prusti](https://github.com/viperproject/prusti-dev/)), it would be extremely useful if we were able to "copy" the implementation of the `mir_drops_elaborated_and_const_checked` query to override it. This would mean that the following items would need to be made public:
>6d55184d05/compiler/rustc_mir_transform/src/lib.rs (L434)
>6d55184d05/compiler/rustc_mir_transform/src/inline.rs (L32)
(for the latter its module needs to be public or it needs to be re-exported)
To explain why (we think) this is necessary: I am currently working on a new feature, where we try to modify the generated executables by inserting certain additional checks, and potentially perform some optimizations based on verification results.
We are using the rust compiler interface and most of our goals can be achieved by overriding queries, in our case this is currently `mir_drops_elaborated_and_const_checked`.
However, at the moment this approach is somewhat limited. When overriding queries, we can call and steal the base-query and then modify the results before allocating and returning those.
The problem is that the verification works with a copy of `mir_promoted`. For the modifications we want to make to the mir, we would often want to rely on results of the verifier that refer to Locations in the `mir_promoted`. We can not modify the `mir_promoted` query using these results, because to run the verification we also need the results of `mir_borrowck()`, which means `mir_promoted` will already be constructed and cached.
The Locations we get from the verifier are also no longer usable to modify `mir_drops_elaborated_and_const_checked`, because the MIR obviously changes between those 2 phases. Tracking all Locations between the two seems to be pretty much unfeasible, and would also be extremely unstable.
By being able to override the query with its original implementation, we could modify the MIR before drop elaboration and the various other passes are performed.
I have spent quite a bit of time investigating other solutions, and didn't find any other way solving this problem. If I still missed something I would of course be happy to hear any suggestions that do not require exposing more internal compiler functionality. However, I think being able to re-implement certain queries could also benefit other use cases in the future, for example in PR #108328 one of the approaches discussed involved doing the same thing for `mir_promoted`.
update llvm-wrapper include to silence deprecation warning
Includes of `include/llvm/Support/Host.h` now emit a deprecated warning: `warning: This header is deprecated, please use llvm/TargetParser/Host.h`.
I don't believe we are using this include.
I don't believe we need to bump the `download-ci-llvm` stamp since these warnings are emitted while building the `llvm-wrapper`.
r? ```@nikic```
CFI: Fix error compiling core with LLVM CFI enabled
Fix#90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
add aarch64-unknown-teeos target
TEEOS is a mini os run in TrustZone, for trusted/security apps. The libc of TEEOS is a part of musl. The kernel of TEEOS is micro kernel.
This MR is to add a target for teeos.
MRs for libc and rust-std are in progress.
Compiler team MCP: [MCP](https://github.com/rust-lang/compiler-team/issues/652)
