| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
|
|
|
|
|
|
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`.
|
|
Add `lazy_type_alias` feature gate
Add the `type_alias_type` to be able to have the weak alias used without restrictions.
Part of #112792.
cc `@compiler-errors`
r? `@oli-obk`
|
|
|
|
Syntactically accept `become` expressions (explicit tail calls experiment)
This adds `ast::ExprKind::Become`, implements parsing and properly gates the feature.
cc `@scottmcm`
|
|
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
https://github.com/rust-lang/rust/blob/2f896da247e0ee8f0bef7cd7c54cfbea255b9f68/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L61-L132
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`
|
|
|
|
|
|
Simplify `Span::source_callee` impl
Imo the iterator impl is easier to grasp.
|
|
|
|
Remove `box_free` lang item
This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
|
|
|
|
Add `SyntaxContext::is_root`
Makes the code a tad nicer.
|
|
|
|
|
|
|
|
|
|
Fix issue for module name when surround the struct literal with parentheses
Fixes #112278
|
|
|
|
|
|
|
|
Uplift `clippy::cast_ref_to_mut` lint
This PR aims at uplifting the `clippy::cast_ref_to_mut` lint into rustc.
## `cast_ref_to_mut`
(deny-by-default)
The `cast_ref_to_mut` lint checks for casts of `&T` to `&mut T` without using interior mutability.
### Example
```rust,compile_fail
fn x(r: &i32) {
unsafe {
*(r as *const i32 as *mut i32) += 1;
}
}
```
### Explanation
Casting `&T` to `&mut T` without interior mutability is undefined behavior, as it's a violation of Rust reference aliasing requirements.
-----
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
-----
For Clippy:
changelog: Moves: Uplifted `clippy::cast_ref_to_mut` into rustc
|
|
Only rewrite valtree-constants to patterns and keep other constants opaque
Now that we can reliably fall back to comparing constants with `PartialEq::eq` to the match scrutinee, we can
1. eagerly try to convert constants to valtrees
2. then deeply convert the valtree to a pattern
3. if the to-valtree conversion failed, create an "opaque constant" pattern.
This PR specifically avoids any behavioral changes or major cleanups. What we can now do as follow ups is
* move the two remaining call sites to `destructure_mir_constant` off that query
* make valtree to pattern conversion infallible
* this needs to be done after careful analysis of the effects. There may be user visible changes from that.
based on https://github.com/rust-lang/rust/pull/111768
|
