| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Add links to the reference and rust by example for asm! docs and lints
These were previously removed in #91728 due to broken links.
cc ``@ehuss`` since this updates the rust-by-example submodule
|
|
|
|
Suggest tuple-parentheses for enum variants
This follows on from #86493 / #86481, making the parentheses suggestion. To summarise, given the following code:
```rust
fn f() -> Option<(i32, i8)> {
Some(1, 2)
}
```
The current output is:
```
error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied
--> b.rs:2:5
|
2 | Some(1, 2)
| ^^^^ - - supplied 2 arguments
| |
| expected 1 argument
error: aborting due to previous error
For more information about this error, try `rustc --explain E0061`.
```
With this change, `rustc` will now suggest parentheses when:
- The callee is expecting a single tuple argument
- The number of arguments passed matches the element count in the above tuple
- The arguments' types match the tuple's fields
```
error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied
--> b.rs:2:5
|
2 | Some(1, 2)
| ^^^^ - - supplied 2 arguments
|
help: use parentheses to construct a tuple
|
2 | Some((1, 2))
| + +
```
|
|
Instead, just use a term everywhere.
|
|
|
|
|
|
|
|
Make available the remaining float intrinsics that require runtime support
from a platform's libm, and thus cannot be included in a no-deps libcore,
by exposing them through a sealed trait, `std::simd::StdFloat`.
We might use the trait approach a bit more in the future, or maybe not.
Ideally, this trait doesn't stick around, even if so.
If we don't need to intermesh it with std, it can be used as a crate,
but currently that is somewhat uncertain.
|
|
|
|
|
|
|
|
Ignore unwinding edges when checking for unconditional recursion
The unconditional recursion lint determines if all execution paths
eventually lead to a self-recursive call.
The implementation always follows unwinding edges which limits its
practical utility. For example, it would not lint function `f` because a
call to `g` might unwind. It also wouldn't lint function `h` because an
overflow check preceding the self-recursive call might unwind:
```rust
pub fn f() {
g();
f();
}
pub fn g() { /* ... */ }
pub fn h(a: usize) {
h(a + 1);
}
```
To avoid the issue, assume that terminators that might continue
execution along non-unwinding edges do so.
Fixes #78474.
|
|
|
|
Improve selection errors for `~const` trait bounds
|
|
|
|
|
|
The unconditional recursion lint determines if all execution paths
eventually lead to a self-recursive call.
The implementation always follows unwinding edges which limits its
practical utility. For example, it would not lint function `f` because a
call to `g` might unwind. It also wouldn't lint function `h` because an
overflow check preceding the self-recursive call might unwind:
```rust
pub fn f() {
g();
f();
}
pub fn g() { /* ... */ }
pub fn h(a: usize) {
h(a + 1);
}
```
To avoid the issue, assume that terminators that might continue
execution along non-unwinding edges do so.
|
|
|
|
Does nothing at runtime.
`const_allocate`: Returns a null pointer at runtime.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix ICE when parsing bad turbofish with lifetime argument
Generalize conditions where we suggest adding the turbofish operator, so we don't ICE during code like
```rust
fn foo() {
A<'a,>
}
```
but instead suggest adding a turbofish.
Fixes #93282
|
|
Remove deduplication of early lints
We already have a general mechanism for deduplicating reported
lints, so there's no need to have an additional one for early lints
specifically. This allows us to remove some `PartialEq` impls.
|
|
|
|
|
|
|
|
|
|
r=nikomatsakis
Implement stable overlap check considering negative traits
This PR implement the new disjointness rules for overlap check described in https://rust-lang.github.io/negative-impls-initiative/explainer/coherence-check.html#new-disjointness-rules
r? ``@nikomatsakis``
|
|
Move param count error emission to end of `check_argument_types`
The error emission here isn't exactly what is done in #92364, but replicating that is hard . The general move should make for a smaller diff.
Also included the `(usize, Ty, Ty)` to -> `Option<(Ty, Ty)>` commit.
r? ``@estebank``
|
|
r=the8472
Revert "Do not hash leading zero bytes of i64 numbers in Sip128 hasher"
Reverts rust-lang/rust#92103. It had a (in retrospect, obvious) correctness problem where changing the order of two adjacent values would produce identical hashes, which is problematic in stable hashing (see [this comment](https://github.com/rust-lang/rust/pull/92103#issuecomment-1014625442)).
I'll try to send the PR again with a fix for this issue.
r? `@the8472`
|
|
|
|
Check `const Drop` impls considering `~const` Bounds
This PR adds logic to trait selection to account for `~const` bounds in custom `impl const Drop` for types, elaborates the `const Drop` check in `rustc_const_eval` to check those bounds, and steals some drop linting fixes from #92922, thanks `@DrMeepster.`
r? `@fee1-dead` `@oli-obk` <sup>(edit: guess I can't request review from two people, lol)</sup>
since each of you wrote and reviewed #88558, respectively.
Since the logic here is more complicated than what existed, it's possible that this is a perf regression. But it works correctly with tests, and that makes me happy.
Fixes #92881
|
|
We already have a general mechanism for deduplicating reported
lints, so there's no need to have an additional one for early lints
specifically. This allows us to remove some `PartialEq` impls.
|
|
Liberate late bound regions when collecting GAT substs in wfcheck
The issue here is that the [`GATSubstCollector`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_typeck/src/check/wfcheck.rs#L604) does not currently do anything wrt `Binder`s, so the GAT substs it copies out have escaping late bound regions when it walks through types like `for<'x> fn() -> Self::Gat<'x>`.
I made that visitor call `liberate_late_bound_regions`, not sure if that's the right thing here or we need to do something else to replace these bound vars with placeholders. I'm not familiar with other code doing anything similar.. But the issue is indeed no longer ICEing.
Fixes #92954
r? `@jackh726`
since you last touched this code, feel free to reassign
|
|
Normalize field access types during borrowck
I think a normalize was just left out here, since we normalize analogously throughout this file.
Fixes #93141
|
|
Fix `let_chains` and `if_let_guard` feature flags
Fixes https://github.com/rust-lang/rust/issues/93150
cc #53667
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #90666 (Stabilize arc_new_cyclic)
- #91122 (impl Not for !)
- #93068 (Fix spacing for `·` between stability and source)
- #93103 (Tweak `expr.await` desugaring `Span`)
- #93113 (Unify search input and buttons size)
- #93168 (update uclibc instructions for new toolchain, add link from platforms doc)
- #93185 (rustdoc: Make some `pub` items crate-private)
- #93196 (Remove dead code from build_helper)
Failed merges:
- #93188 (rustdoc: fix bump down typing search on Safari)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Disable drop range tracking in generators
Generator drop tracking caused an ICE for generators involving the Never type (Issue #93161). Since this breaks a test case with miri, we temporarily disable drop tracking so miri is unblocked while we properly fix the issue.
|
|
Previously, when rustc was provided an async function that tried to
mutate through a shared reference to an implicit self (as shown in the
ui test), rustc would suggest modifying the parameter signature
to `&mut` + the fully qualified name of the ty (in the case of the repro
`S`). If a user modified their code to match the suggestion, the
compiler would not accept it.
This commit modifies the suggestion so that when rustc is provided the
ui test that is also attached in this commit, it suggests (correctly)
`&mut self`. We try to be careful about distinguishing between implicit
and explicit self annotations, since the latter seem to be handled
correctly already.
Fixes rust-lang/rust#93093
|
|
Tweak `expr.await` desugaring `Span`
Fix #93074
|
|
impl Not for !
The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}`, even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression, which would otherwise be perfectly legal in boolean position, the code previously failed to compile with:
```console
error[E0600]: cannot apply unary operator `!` to type `!`
--> library/core/tests/ops.rs:239:8
|
239 | if !return () {}
| ^^^^^^^^^^ cannot apply unary operator `!`
```
|
|
|
