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.
Add support for tidy linting via external tools for non-rust files
This change adds the flag `--check-extras` to `tidy`. It accepts a comma separated list of any of the options:
* py (test everything applicable for python files)
* py:lint (lint python files using `ruff`)
* py:fmt (check formatting for python files using `black`)
* shell or shell:lint (lint shell files using `shellcheck`)
Specific files to check can also be specified via positional args. Examples:
* `./x test tidy --check-extras=shell,py`
* `./x test tidy --check-extras=py:fmt -- src/bootstrap/bootstrap.py`
* `./x test tidy --check-extras=shell -- src/ci/*.sh`
* Python formatting can be applied with bless: `./x test tidy --ckeck-extras=py:fmt --bless`
`ruff` and `black` need to be installed via pip; this tool manages these within a virtual environment at `build/venv`. `shellcheck` needs to be installed on the system already.
---
This PR doesn't fix any of the errors that show up (I will likely go through those at some point) and it doesn't enforce anything new in CI. Relevant zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Other.20linters.20in.20CI
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.
test_get_dbpath_for_term(): handle non-utf8 paths (fix FIXME)
Removes a FIXME for #9639
Part of #44366 which is E-help-wanted
The remaining two FIXMEs for #9639 are considerably more complicated, so I will create separate PRs for them.
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
Sync rustc_codegen_cranelift
A couple of small bug fixes this time. In addition I fixed the test suite after the introduction of `#![deny(internal_feature)]` broke it.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
[`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse
#11198 extended this lint to also warn on `Vec::new()` + `resize(0, len)`, but did not update the lint documentation, so it left some confused (https://github.com/rust-lang/rust-clippy/issues/10938#issuecomment-1663880083).
This PR should make it a bit more clear. (cc `@djc` `@vi` what do you think about this?)
<details>
<summary>More details</summary>
Godbolt for `Vec::new()` + `.resize(x, 0)`: https://godbolt.org/z/e7q9xc9rG
The resize call first does a normal allocation (`__rust_alloc`):
```asm
alloc::raw_vec::finish_grow:
...
cmp qword ptr [rcx + 8], 0
je .LBB1_7 ; if capacity == 0 -> LBB1_7
.LBB1_7:
...
call qword ptr [rip + __rust_alloc@GOTPCREL]
```
*Then* a memset for zero initialization:
```asm
example::f:
...
xor esi, esi ; 0
call qword ptr [rip + memset@GOTPCREL]
```
------------
Godbolt for `vec![0; len]`: https://godbolt.org/z/M3vr53vWY
Important bit:
```asm
example::f:
...
call qword ptr [rip + __rust_alloc_zeroed@GOTPCREL]
```
</details>
changelog: [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse than `vec![0; len]`
