| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Prevent multiple 'ignored unless specified at crate level' lints. The
multiplication happens because we run the same lint three times:
* In BuiltinCombinedEarlyLintPass
* In BuiltinCombinedPreExpansionLintPass
* In shallow_lint_levels_on
Only run the lint one time by checking the `lint_added_lints` bool.
|
|
Fix parenthesization of subexprs containing statement boundary
This PR fixes a multitude of false negatives and false positives in the AST pretty printer's parenthesis insertion related to statement boundaries — statements which terminate unexpectedly early if there aren't parentheses.
Without this fix, the AST pretty printer (including both `stringify!` and `rustc -Zunpretty=expanded`) is prone to producing output which is not syntactically valid Rust. Invalid output is problematic because it means Rustfmt is unable to parse the output of `cargo expand`, for example, causing friction by forcing someone trying to debug a macro into reading poorly formatted code.
I believe the set of bugs fixed in this PR account for the most prevalent reason that `cargo expand` produces invalid output in real-world usage.
Fixes #98790.
## False negatives
The following is a correct program — `cargo check` succeeds.
```rust
macro_rules! m {
($e:expr) => {
match () { _ => $e }
};
}
fn main() {
m!({ 1 } - 1);
}
```
But `rustc -Zunpretty=expanded main.rs` produces output that is invalid Rust syntax, because parenthesization is needed and not being done by the pretty printer.
```rust
fn main() { match () { _ => { 1 } - 1, }; }
```
Piping this expanded code to rustfmt, it fails to parse.
```console
error: unexpected `,` in pattern
--> <stdin>:1:38
|
1 | fn main() { match () { _ => { 1 } - 1, }; }
| ^
|
help: try adding parentheses to match on a tuple...
|
1 | fn main() { match () { _ => { 1 } (- 1,) }; }
| + +
help: ...or a vertical bar to match on multiple alternatives
|
1 | fn main() { match () { _ => { 1 } - 1 | }; }
| ~~~~~
```
Fixed output after this PR:
```rust
fn main() { match () { _ => ({ 1 }) - 1, }; }
```
## False positives
Less problematic, but worth fixing (just like #118726).
```rust
fn main() {
let _ = match () { _ => 1 } - 1;
}
```
Output of `rustc -Zunpretty=expanded lib.rs` before this PR. There is no reason parentheses would need to be inserted there.
```rust
fn main() { let _ = (match () { _ => 1, }) - 1; }
```
After this PR:
```rust
fn main() { let _ = match () { _ => 1, } - 1; }
```
## Alternatives considered
In this PR I opted to parenthesize only the leading subexpression causing the statement boundary, rather than the entire statement. Example:
```rust
macro_rules! m {
($e:expr) => {
$e
};
}
fn main() {
m!(loop { break [1]; }[0] - 1);
}
```
This PR produces the following pretty-printed contents for fn main:
```rust
(loop { break [1]; })[0] - 1;
```
A different equally correct output would be:
```rust
(loop { break [1]; }[0] - 1);
```
I chose the one I did because it is the *only* approach used by handwritten code in the standard library and compiler. There are 4 places where parenthesization is being used to prevent a statement boundary, and in all 4, the developer has chosen to parenthesize the smallest subexpression rather than the whole statement:
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_codegen_cranelift/example/alloc_system.rs#L102
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_parse/src/errors.rs#L1021-L1029
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/future/poll_fn.rs#L151
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/ops/range.rs#L824-L828
|
|
Introduce `const Trait` (always-const trait bounds)
Feature `const_trait_impl` currently lacks a way to express “always const” trait bounds. This makes it impossible to define generic items like fns or structs which contain types that depend on const method calls (\*). While the final design and esp. the syntax of effects / keyword generics isn't set in stone, some version of “always const” trait bounds will very likely form a part of it. Further, their implementation is trivial thanks to the `effects` backbone.
Not sure if this needs t-lang sign-off though.
(\*):
```rs
#![feature(const_trait_impl, effects, generic_const_exprs)]
fn compute<T: const Trait>() -> Type<{ T::generate() }> { /*…*/ }
struct Store<T: const Trait>
where
Type<{ T::generate() }>:,
{
field: Type<{ T::generate() }>,
}
```
Lastly, “always const” trait bounds are a perfect fit for `generic_const_items`.
```rs
#![feature(const_trait_impl, effects, generic_const_items)]
const DEFAULT<T: const Default>: T = T::default();
```
Previously, we (oli, fee1-dead and I) wanted to reinterpret `~const Trait` as `const Trait` in generic const items which would've been quite surprising and not very generalizable.
Supersedes #117530.
---
cc `@oli-obk`
As discussed
r? fee1-dead (or compiler)
|
|
Suggest `=>` --> `>=` in comparisons
Fixes #117245
|
|
|
|
rustdoc: treat query string `+` as space
Fixes #119219
|
|
fix: diagnostic for casting reference to slice
fixes: #118790
Removes `if self.cast_ty.is_trait()` to produce the same diagnostic for cast to slice and trait.
|
|
|
|
Given `foo: &String` and `bar: str`, suggest `==` when given `if foo = bar {}`:
```
error[E0308]: mismatched types
--> $DIR/assignment-expected-bool.rs:37:8
|
LL | if foo = bar {}
| ^^^^^^^^^ expected `bool`, found `()`
|
help: you might have meant to compare for equality
|
LL | if foo == bar {}
| +
```
|
|
Emit better suggestions for `&T == T` and `T == &T`
Fixes #40660
Fixes #44695
|
|
Fixes #119219
|
|
Rollup of 5 pull requests
Successful merges:
- #119235 (Add missing feature gate for sanitizer CFI cfgs)
- #119240 (Make some non-diagnostic-affecting `QPath::LangItem` into regular `QPath`s)
- #119297 (Pass DeadItem and lint as consistent group in dead-code.)
- #119307 (Clean up some lifetimes in `rustc_pattern_analysis`)
- #119323 (add test for coercing never to infinite type)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add test for coercing never to infinite type
Closes https://github.com/rust-lang/rust/issues/113197.
This was fixed in https://github.com/rust-lang/rust/pull/118308, probably https://github.com/rust-lang/rust/pull/118308/commits/1978168c136ba65b8da3f5a45834631c13d7c56f.
|
|
Pass DeadItem and lint as consistent group in dead-code.
Fixes https://github.com/rust-lang/rust/issues/119267
|
|
Make some non-diagnostic-affecting `QPath::LangItem` into regular `QPath`s
The rest of 'em affect diagnostics, so leave them alone... for now.
cc #115178
|
|
r=Nilstrieb
Add missing feature gate for sanitizer CFI cfgs
Found during the review of https://github.com/rust-lang/rust/pull/118494 in https://github.com/rust-lang/rust/pull/118494#discussion_r1416079288.
cc `@rcvalle`
|
|
fallback `default` to `None` during ast-lowering for lifetime binder
Fixes #118697
This is another attempt. It has a fallback, setting `default` to `None` and emit an error for non-lifetime binders during ast lowering.
r? `@compiler-errors`
|
|
|
|
|
|
Add `hint::assert_unchecked`
Libs-API expressed interest, modulo bikeshedding, in https://github.com/rust-lang/libs-team/issues/315#issuecomment-1863159430
I think that means this is good for nightly, since we can always rename it before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/119131
|
|
rework `-Zverbose`
implements the changes described in https://github.com/rust-lang/compiler-team/issues/706
the first commit is only a name change from `-Zverbose` to `-Zverbose-internals` and does not change behavior. the second commit changes diagnostics.
possible follow up work:
- `ty::pretty` could print more info with `--verbose` than it does currently. `-Z verbose-internals` shows too much info in a way that's not helpful to users. michael had ideas about this i didn't fully understand: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408984200
- `--verbose` should imply `-Z write-long-types-to-disk=no`. the code in `ty_string_with_limit` should take `--verbose` into account (apparently this affects `Ty::sort_string`, i'm not familiar with this code). writing a file to disk should suggest passing `--verbose`.
r? `@compiler-errors` cc `@estebank`
|
|
|
|
Make closures carry their own ClosureKind
Right now, we use the "`movability`" field of `hir::Closure` to distinguish a closure and a coroutine. This is paired together with the `CoroutineKind`, which is located not in the `hir::Closure`, but the `hir::Body`. This is strange and redundant.
This PR introduces `ClosureKind` with two variants -- `Closure` and `Coroutine`, which is put into `hir::Closure`. The `CoroutineKind` is thus removed from `hir::Body`, and `Option<Movability>` no longer needs to be a stand-in for "is this a closure or a coroutine".
r? eholk
|
|
|
|
r=compiler-errors
Remove `DiagCtxt` API duplication
`DiagCtxt` defines the internal API for creating and emitting diagnostics: methods like `struct_err`, `struct_span_warn`, `note`, `create_fatal`, `emit_bug`. There are over 50 methods.
Some of these methods are then duplicated across several other types: `Session`, `ParseSess`, `Parser`, `ExtCtxt`, and `MirBorrowckCtxt`. `Session` duplicates the most, though half the ones it does are unused. Each duplicated method just calls forward to the corresponding method in `DiagCtxt`. So this duplication exists to (in the best case) shorten chains like `ecx.tcx.sess.parse_sess.dcx.emit_err()` to `ecx.emit_err()`.
This API duplication is ugly and has been bugging me for a while. And it's inconsistent: there's no real logic about which methods are duplicated, and the use of `#[rustc_lint_diagnostic]` and `#[track_caller]` attributes vary across the duplicates.
This PR removes the duplicated API methods and makes all diagnostic creation and emission go through `DiagCtxt`. It also adds `dcx` getter methods to several types to shorten chains. This approach scales *much* better than API duplication; indeed, the PR adds `dcx()` to numerous types that didn't have API duplication: `TyCtxt`, `LoweringCtxt`, `ConstCx`, `FnCtxt`, `TypeErrCtxt`, `InferCtxt`, `CrateLoader`, `CheckAttrVisitor`, and `Resolver`. These result in a lot of changes from `foo.tcx.sess.emit_err()` to `foo.dcx().emit_err()`. (You could do this with more types, but it gets into diminishing returns territory for types that don't emit many diagnostics.)
After all these changes, some call sites are more verbose, some are less verbose, and many are the same. The total number of lines is reduced, mostly because of the removed API duplication. And consistency is increased, because calls to `emit_err` and friends are always preceded with `.dcx()` or `.dcx`.
r? `@compiler-errors`
|
|
from movability
|
|
make soft_unstable show up in future breakage reports
If we want to break these in the future, let's warn users of affected crates.
|
|
|
|
Give temporaries in if let guards correct scopes
Temporaries in if-let guards have scopes that escape the match arm, this causes problems because the drops might be for temporaries that are not storage live. This PR changes the scope of temporaries in if-let guards to be limited to the arm:
```rust
_ if let Some(s) = std::convert::identity(&Some(String::new())) => {}
// Temporary for Some(String::new()) is dropped here ^
```
We also now deduplicate temporaries between copies of the guard created for or-patterns:
```rust
// Only create a single Some(String::new()) temporary variable
_ | _ if let Some(s) = std::convert::identity(&Some(String::new())) => {}
```
This changes MIR building to pass around `ExprId`s rather than `Expr`s so that we have a way to index different expressions.
cc #51114
Closes #116079
|
|
Fix display of warning block if it is first element of the top doc block
It fixes the display of the warning block "i" element in case it is the first element:
It now looks like this:
The update for the `browser-ui-test` framework is because it didn't detect correctly pseudo elements if they ended with a digit or a dash.
r? `@notriddle`
|
|
fix ICE when using raw ptr in a pattern
Fixes https://github.com/rust-lang/rust/issues/119270
|
|
this also changes some parts of lifetime printing, which previously were not gated behind `-Z verbose`
|
|
|
|
Exhaustiveness: Improve complexity on some wide matches
https://github.com/rust-lang/rust/issues/118437 revealed an exponential case in exhaustiveness checking. While [exponential cases are unavoidable](https://compilercrim.es/rust-np/), this one only showed up after my https://github.com/rust-lang/rust/pull/117611 rewrite of the algorithm. I remember anticipating a case like this and dismissing it as unrealistic, but here we are :').
The tricky match is as follows:
```rust
match command {
BaseCommand { field01: true, .. } => {}
BaseCommand { field02: true, .. } => {}
BaseCommand { field03: true, .. } => {}
BaseCommand { field04: true, .. } => {}
BaseCommand { field05: true, .. } => {}
BaseCommand { field06: true, .. } => {}
BaseCommand { field07: true, .. } => {}
BaseCommand { field08: true, .. } => {}
BaseCommand { field09: true, .. } => {}
BaseCommand { field10: true, .. } => {}
// ...20 more of the same
_ => {}
}
```
To fix this, this PR formalizes a concept of "relevancy" (naming is hard) that was already used to decide what patterns to report. Now we track it for every row, which in wide matches like the above can drastically cut on the number of cases we explore. After this fix, the above match is checked with linear-many cases instead of exponentially-many.
Fixes https://github.com/rust-lang/rust/issues/118437
r? `@cjgillot`
|
|
mark ty::Const::Error when meet unsupport ty for const generic params
Close #116796
|
|
|
|
Exhaustiveness: Reveal empty opaques in depth
Follow-up to https://github.com/rust-lang/rust/pull/116821. As noted [there](https://github.com/rust-lang/rust/pull/116821#discussion_r1376673420), the current implementation doesn't detect emptiness of opaques when the opaque is nested inside a type. This doesn't matter for stable behavior (which ignores nested empty types anyway) but does matter for the [`exhaustive_patterns`](https://github.com/rust-lang/rust/issues/51085)/[`min_exhaustive_patterns`](https://github.com/rust-lang/rust/pull/118803) features.
This PR fixes this behavior by adding `InhabitedPredicate::apply_reveal_opaque` that considers opaque types when determining inhabitedness.
r? `@compiler-errors`
|
|
|
|
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier
access.
|
|
add a test for ICE #112822
closes #112822.
|
|
r=aDotInTheVoid
[rustdoc] Add `is_object_safe` information for traits in JSON output
As asked by `@obi1kenobi` [here](https://github.com/rust-lang/rust/pull/113241#issuecomment-1868213677).
cc `@aDotInTheVoid`
r? `@notriddle`
|
|
|
|
|
|
|
|
|
|
Clean up `check_consts` and misc fixes
1. Remove most of the logic around erroring with trait methods. I have kept the part resolving it to a concrete impl, as that is used for const stability checks.
2. Turning on `effects` causes ICE with generic args, due to `~const Tr` when `Tr` is not `#[const_trait]` tripping up expectation in code that handles generic args, more specifically here:
https://github.com/rust-lang/rust/blob/8681e077b8afa99d60acf8f8470a012a3ce709a5/compiler/rustc_hir_analysis/src/astconv/generics.rs#L377
We set `arg_count.correct` to `Err` to correctly signal that an error has already been reported.
3. UI test blesses.
Edit(fmease): Fixes #117244 (UI test is in #119099 for now).
r? compiler-errors
|
|
|
|
|
