| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Fix ABI flags in RISC-V/LoongArch ELF file generated by rustc
Fix #114153
It turns out the current way to set these flags are completely wrong. In LLVM the target ABI is used instead of target features to determine these flags.
Not sure how to write a test though. Or maybe a test isn't necessary because this affects only those touching target json?
r? `@Nilstrieb`
|
|
This way is possible to write inline assembly code aware of it.
|
|
|
|
r=est31
Improve `invalid_reference_casting` lint
This PR improves the `invalid_reference_casting` lint:
- by considering an unlimited number of casts instead only const to mut ptr
- by also considering ptr-to-integer and integer-to-ptr casts
- by also taking into account [`ptr::cast`](https://doc.rust-lang.org/std/primitive.pointer.html#method.cast), [`ptr::cast`](https://doc.rust-lang.org/std/primitive.pointer.html#method.cast-1) and [`ptr::cast_const`](https://doc.rust-lang.org/std/primitive.pointer.html#method.cast_const)
Most of this improvements comes from skimming Github Code Search result for [`&mut \*.*as \*const`](https://github.com/search?q=lang%3Arust+%2F%26mut+%5C*.*as+%5C*const%2F&type=code)
r? ``@est31`` (maybe)
|
|
Fix argument removal suggestion around macros
Fixes #112437.
Fixes #113866.
Helps with #114255.
The issue was that `span.find_ancestor_inside(outer)` could previously return a span with a different expansion context from `outer`.
This happens for example for the built-in macro `panic!`, which expands to another macro call of `panic_2021!` or `panic_2015!`. Because the call site of `panic_20xx!` has not associated source code, its span currently points to the call site of `panic!` instead.
Something similar also happens items that get desugared in AST->HIR lowering. For example, `for` loops get two spans: One "inner" span that has the `.desugaring_kind()` kind set to `DesugaringKind::ForLoop` and one "outer" span that does not. Similar to the macro situation, both of these spans point to the same source code, but have different expansion contexts.
This causes problems, because joining two spans with different expansion contexts will usually[^1] not actually join them together to avoid creating "spaghetti" spans that go from the macro definition to the macro call. For example, in the following snippet `full_span` might not actually contain the `adjusted_start` and `adjusted_end`. This caused the broken suggestion / debug ICE in the linked issues.
```rust
let adjusted_start = start.find_ancestor_inside(shared_ancestor);
let adjusted_end = end.find_ancestor_inside(shared_ancestor);
let full_span = adjusted_start.to(adjusted_end)
```
To fix the issue, this PR introduces a new method, `find_ancestor_inside_same_ctxt`, which combines the functionality of `find_ancestor_inside` and `find_ancestor_in_same_ctxt`: It finds an ancestor span that is contained within the parent *and* has the same syntax context, and is therefore safe to extend. This new method should probably be used everywhere, where the returned span is extended, but for now it is just used for the argument removal suggestion.
Additionally, this PR fixes a second issue where the function call itself is inside a macro but the arguments come from outside the macro. The test is added in the first commit to include stderr diff, so this is best reviewed commit by commit.
[^1]: If one expansion context is the root context and the other is not.
|
|
Add `{Local}ModDefId` to more strongly type DefIds`
Based on #110862 by `@Nilstrieb`
|
|
|
|
|
|
|
|
This allows for better type safety in the compiler and also improves the
documentation for many things, making it clear that they expect modules.
|
|
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]: https://github.com/esp-rs/esp-riscv-rt/blob/9281af2ecffe13e40992917316f36920c26acaf3/src/lib.rs#L440-L469
[implemented by]: https://github.com/llvm/llvm-project/blob/b7fb2a3fec7c187d58a6d338ab512d9173bca987/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp#L61-L67
[callee-save]: https://github.com/llvm/llvm-project/blob/973f1fe7a8591c7af148e573491ab68cc15b6ecf/llvm/lib/Target/RISCV/RISCVCallingConv.td#L30-L37
[rfc]: https://github.com/rust-lang/rfcs/pull/3246
|
|
Style fix and refactor on resolve diagnostics
- coding style
- refactor api of `span_look_ahead`
|
|
|
|
|
|
It was added by #113657 for its purposes.
Now it is not used any more, remove it,
as we use the attr now.
|
|
And look for it in the useless_ptr_null_checks lint
|
|
Add separate feature gate for async fn track caller
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes #110009
|
|
[rustc_span][perf] Remove unnecessary string joins and allocs.
Comparing vectors of string parts yields the same result but avoids unnecessary `join` and potential allocation for resulting `String`. This code is cold so it's unlikely to have any measurable impact, but considering but since it's also simpler, why not? :)
|
|
Add `internal_features` lint
Implements https://github.com/rust-lang/compiler-team/issues/596
Also requires some more test blessing for codegen tests etc
`@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.
|
|
[rustc_span][perf] Hoist lookup sorted by words out of the loop.
```@lqd``` commented on https://github.com/rust-lang/rust/pull/114351 asking if `sort_by_words(lookup)` is computed repeatedly. I was assuming that rustc should have no difficulties to hoist it automatically outside of the loop to avoid repeated pure computation, but according to
https://godbolt.org/z/frs8Kj1rq it seems like I was wrong:
original version seems to have 2 calls per loop iteration
```
.LBB16_3:
mov rbx, qword ptr [r13]
mov r14, qword ptr [r13 + 8]
lea rdi, [rsp + 40]
mov rsi, rbx
mov rdx, r14
call example::sort_by_words
lea rdi, [rsp + 64]
mov rsi, qword ptr [rsp + 8]
mov rdx, qword ptr [rsp + 16]
call example::sort_by_words
mov rdi, qword ptr [rsp + 40]
mov rdx, qword ptr [rsp + 56]
mov rsi, qword ptr [rsp + 64]
cmp rdx, qword ptr [rsp + 80]
mov qword ptr [rsp + 32], rdi
mov qword ptr [rsp + 24], rsi
jne .LBB16_5
call qword ptr [rip + bcmp@GOTPCREL]
test eax, eax
sete al
mov dword ptr [rsp + 4], eax
mov rsi, qword ptr [rsp + 72]
test rsi, rsi
jne .LBB16_8
jmp .LBB16_9
```
but the manually hoisted version just 1:
```
.LBB16_3:
mov r13, qword ptr [r15]
mov r14, qword ptr [r15 + 8]
lea rdi, [rsp + 64]
mov rsi, r13
mov rdx, r14
call example::sort_by_words
mov rdi, qword ptr [rsp + 64]
mov rdx, qword ptr [rsp + 16]
cmp qword ptr [rsp + 80], rdx
mov qword ptr [rsp + 32], rdi
jne .LBB16_5
mov rsi, qword ptr [rsp + 8]
call qword ptr [rip + bcmp@GOTPCREL]
test eax, eax
sete bpl
mov rsi, qword ptr [rsp + 72]
test rsi, rsi
jne .LBB16_8
jmp .LBB16_9
```
This code is probably not very hot, but there is no reason to leave such a low hanging fruit.
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
@lqd commented on https://github.com/rust-lang/rust/pull/114351 asking
if `sort_by_words(lookup)` is computed repeatedly. I was assuming that
rustc should have no difficulties to hoist it automatically outside of
the loop to avoid repeated pure computation, but according to
https://godbolt.org/z/frs8Kj1rq it seems like I was wrong:
original version seems to have 2 calls per loop iteration
```
.LBB16_3:
mov rbx, qword ptr [r13]
mov r14, qword ptr [r13 + 8]
lea rdi, [rsp + 40]
mov rsi, rbx
mov rdx, r14
call example::sort_by_words
lea rdi, [rsp + 64]
mov rsi, qword ptr [rsp + 8]
mov rdx, qword ptr [rsp + 16]
call example::sort_by_words
mov rdi, qword ptr [rsp + 40]
mov rdx, qword ptr [rsp + 56]
mov rsi, qword ptr [rsp + 64]
cmp rdx, qword ptr [rsp + 80]
mov qword ptr [rsp + 32], rdi
mov qword ptr [rsp + 24], rsi
jne .LBB16_5
call qword ptr [rip + bcmp@GOTPCREL]
test eax, eax
sete al
mov dword ptr [rsp + 4], eax
mov rsi, qword ptr [rsp + 72]
test rsi, rsi
jne .LBB16_8
jmp .LBB16_9
```
but the manually hoisted version just 1:
```
.LBB16_3:
mov r13, qword ptr [r15]
mov r14, qword ptr [r15 + 8]
lea rdi, [rsp + 64]
mov rsi, r13
mov rdx, r14
call example::sort_by_words
mov rdi, qword ptr [rsp + 64]
mov rdx, qword ptr [rsp + 16]
cmp qword ptr [rsp + 80], rdx
mov qword ptr [rsp + 32], rdi
jne .LBB16_5
mov rsi, qword ptr [rsp + 8]
call qword ptr [rip + bcmp@GOTPCREL]
test eax, eax
sete bpl
mov rsi, qword ptr [rsp + 72]
test rsi, rsi
jne .LBB16_8
jmp .LBB16_9
```
This code is probably not very hot, but there is no reason to leave
such a low hanging fruit.
|
|
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes #110009
|
|
Comparing vectors of string parts yields the same result but avoids
unnecessary `join` and potential allocation for resulting `String`.
This code is cold so it's unlikely to have any measurable impact, but
considering but since it's also simpler, why not? :)
|
|
|
|
and use it for function argument diagnostics
|
|
|
|
Add simd_bswap, simd_bitreverse, simd_ctlz, and simd_cttz intrinsics
cc `@workingjubilee`
|
|
|
|
Co-authored-by: est31 <est31@users.noreply.github.com>
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
|
|
|
|
|
|
|
|
"no method" errors on standard library types
The standard library developer can annotate methods on e.g.
`BTreeSet::push` with `#[rustc_confusables("insert")]`. When the user
mistypes `btreeset.push()`, `BTreeSet::insert` will be suggested if
there are no other candidates to suggest.
|
|
|
|
|
|
Uplift `clippy::fn_null_check` lint
This PR aims at uplifting the `clippy::fn_null_check` lint into rustc.
## `incorrect_fn_null_checks`
(warn-by-default)
The `incorrect_fn_null_checks` lint checks for expression that checks if a function pointer is null.
### Example
```rust
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
if (fn_ptr as *const ()).is_null() { /* ... */ }
```
### Explanation
Function pointers are assumed to be non-null, checking for their nullity is incorrect.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
|
|
|
|
The new version was already added to the tree as an indirect dependency
in #113046, but now our direct dependents are using it too.
|
|
|
|
A mish-mash of micro-optimizations
These were aimed at speeding up LLVM codegen, but ended up affecting other places as well.
r? `@bjorn3`
|
|
privacy: Type privacy lints fixes and cleanups
See individual commits.
Follow up to https://github.com/rust-lang/rust/pull/111801.
|
|
This makes it (a) a little simpler, and (b) more similar to
`SourceFile::lookup_line`.
|
