| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 2cb9a65684dba47c52de8fa938febf97a73e70a9, reversing
changes made to 750bd1a7ff3e010611b97ee75d30b7cbf5f3a03c.
(cherry picked from commit fc43df0333d5862a219f16d294ae38b14b9191d3)
|
|
Compute lint levels by definition
Lint levels are currently computed once for the whole crate. Any code that wants to emit a lint depends on this single `lint_levels(())` query. This query contains the `Span` for each attribute that participates in the lint level tree, so any code that wants to emit a lint basically depends on the spans in all files in the crate.
Contrary to hard errors, we do not clear the incremental session on lints, so this implicit world dependency pessimizes incremental reuse. (And is furthermore invisible for allowed lints.)
This PR completes https://github.com/rust-lang/rust/pull/99634 (thanks for the initial work `@fee1-dead)` and includes it in the dependency graph.
The design is based on 2 queries:
1. `lint_levels_on(HirId) -> FxHashMap<LintId, LevelAndSource>` which accesses the attributes at the given `HirId` and processes them into lint levels. The `TyCtxt` is responsible for probing the HIR tree to find the user-visible level.
2. `lint_expectations(())` which lists all the `#[expect]` attributes in the crate.
This PR also introduces the ability to reconstruct a `HirId` from a `DepNode` by encoding the local part of the `DefPathHash` and the `ItemLocalId` in the two `u64` of the fingerprint. This allows for the dep-graph to directly recompute `lint_levels_on` directly, without having to force the calling query.
Closes https://github.com/rust-lang/rust/issues/95094.
Supersedes https://github.com/rust-lang/rust/pull/99634.
|
|
|
|
|
|
|
|
|
|
Uplift the `let_underscore` lints from clippy into rustc.
This PR resolves #97241.
This PR adds three lints from clippy--`let_underscore_drop`, `let_underscore_lock`, and `let_underscore_must_use`, which are meant to capture likely-incorrect uses of `let _ = ...` bindings (in particular, doing this on a type with a non-trivial `Drop` causes the `Drop` to occur immediately, instead of at the end of the scope. For a type like `MutexGuard`, this effectively releases the lock immediately, which is almost certainly the wrong behavior)
In porting the lints from clippy I had to copy over a bunch of utility functions from `clippy_util` that these lints also relied upon. Is that the right approach?
Note that I've set the `must_use` and `drop` lints to Allow by default and set `lock` to Deny by default (this matches the same settings that clippy has). In talking with `@estebank` he informed me to do a Crater run (I am not sure what type of Crater run to request here--I think it's just "check only"?)
On the linked issue, there's some discussion about using `must_use` and `Drop` together as a heuristic for when to warn--I did not implement this yet.
r? `@estebank`
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
|
|
|
|
Stabilize `#![feature(label_break_value)]`
See the stabilization report in https://github.com/rust-lang/rust/issues/48594#issuecomment-1186213313.
|
|
# Stabilization proposal
The feature was implemented in https://github.com/rust-lang/rust/pull/50045 by est31 and has been in nightly since 2018-05-16 (over 4 years now).
There are [no open issues][issue-label] other than the tracking issue. There is a strong consensus that `break` is the right keyword and we should not use `return`.
There have been several concerns raised about this feature on the tracking issue (other than the one about tests, which has been fixed, and an interaction with try blocks, which has been fixed).
1. nrc's original comment about cost-benefit analysis: https://github.com/rust-lang/rust/issues/48594#issuecomment-422235234
2. joshtriplett's comments about seeing use cases: https://github.com/rust-lang/rust/issues/48594#issuecomment-422281176
3. withoutboats's comments that Rust does not need more control flow constructs: https://github.com/rust-lang/rust/issues/48594#issuecomment-450050630
Many different examples of code that's simpler using this feature have been provided:
- A lexer by rpjohnst which must repeat code without label-break-value: https://github.com/rust-lang/rust/issues/48594#issuecomment-422502014
- A snippet by SergioBenitez which avoids using a new function and adding several new return points to a function: https://github.com/rust-lang/rust/issues/48594#issuecomment-427628251. This particular case would also work if `try` blocks were stabilized (at the cost of making the code harder to optimize).
- Several examples by JohnBSmith: https://github.com/rust-lang/rust/issues/48594#issuecomment-434651395
- Several examples by Centril: https://github.com/rust-lang/rust/issues/48594#issuecomment-440154733
- An example by petrochenkov where this is used in the compiler itself to avoid duplicating error checking code: https://github.com/rust-lang/rust/issues/48594#issuecomment-443557569
- Amanieu recently provided another example related to complex conditions, where try blocks would not have helped: https://github.com/rust-lang/rust/issues/48594#issuecomment-1184213006
Additionally, petrochenkov notes that this is strictly more powerful than labelled loops due to macros which accidentally exit a loop instead of being consumed by the macro matchers: https://github.com/rust-lang/rust/issues/48594#issuecomment-450246249
nrc later resolved their concern, mostly because of the aforementioned macro problems.
joshtriplett suggested that macros could be able to generate IR directly
(https://github.com/rust-lang/rust/issues/48594#issuecomment-451685983) but there are no open RFCs,
and the design space seems rather speculative.
joshtriplett later resolved his concerns, due to a symmetry between this feature and existing labelled break: https://github.com/rust-lang/rust/issues/48594#issuecomment-632960804
withoutboats has regrettably left the language team.
joshtriplett later posted that the lang team would consider starting an FCP given a stabilization report: https://github.com/rust-lang/rust/issues/48594#issuecomment-1111269353
[issue-label]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AF-label_break_value+
## Report
+ Feature gate:
- https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/src/test/ui/feature-gates/feature-gate-label_break_value.rs
+ Diagnostics:
- https://github.com/rust-lang/rust/blob/6b2d3d5f3cd1e553d87b5496632132565b6779d3/compiler/rustc_parse/src/parser/diagnostics.rs#L2629
- https://github.com/rust-lang/rust/blob/f65bf0b2bb1a99f73095c01a118f3c37d3ee614c/compiler/rustc_resolve/src/diagnostics.rs#L749
- https://github.com/rust-lang/rust/blob/f65bf0b2bb1a99f73095c01a118f3c37d3ee614c/compiler/rustc_resolve/src/diagnostics.rs#L1001
- https://github.com/rust-lang/rust/blob/111df9e6eda1d752233482c1309d00d20a4bbf98/compiler/rustc_passes/src/loops.rs#L254
- https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/compiler/rustc_parse/src/parser/expr.rs#L2079
- https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/compiler/rustc_parse/src/parser/expr.rs#L1569
+ Tests:
- https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs
## Interactions with other features
Labels follow the hygiene of local variables.
label-break-value is permitted within `try` blocks:
```rust
let _: Result<(), ()> = try {
'foo: {
Err(())?;
break 'foo;
}
};
```
label-break-value is disallowed within closures, generators, and async blocks:
```rust
'a: {
|| break 'a
//~^ ERROR use of unreachable label `'a`
//~| ERROR `break` inside of a closure
}
```
label-break-value is disallowed on [_BlockExpression_]; it can only occur as a [_LoopExpression_]:
```rust
fn labeled_match() {
match false 'b: { //~ ERROR block label not supported here
_ => {}
}
}
macro_rules! m {
($b:block) => {
'lab: $b; //~ ERROR cannot use a `block` macro fragment here
unsafe $b; //~ ERROR cannot use a `block` macro fragment here
|x: u8| -> () $b; //~ ERROR cannot use a `block` macro fragment here
}
}
fn foo() {
m!({});
}
```
[_BlockExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/block-expr.html
[_LoopExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/loop-expr.html
|
|
|
|
Make must_not_suspend lint see through references when drop tracking is enabled
See #97333.
With drop tracking enabled, sometimes values that were previously linted are now considered dropped and not linted. This change makes must_not_suspend traverse through references to still catch these values.
Unfortunately, this leads to duplicate warnings in some cases (e.g. [dedup.rs](https://cs.github.com/rust-lang/rust/blob/9a74608543d499bcc7dd505e195e8bfab9447315/src/test/ui/lint/must_not_suspend/dedup.rs#L4)), so we only use the new behavior when drop tracking is enabled.
cc ``@guswynn``
|
|
This ensures that lint attributes on pattern fields can control
early lints.
|
|
This was incorrectly inserting the ExprField as a sibling of the struct
expression.
This required adjusting various parts which were looking at parent node
of a field expression to find the struct.
|
|
This helps simplify the code. It also fixes it to use the correct parent
when lowering. One consequence is the `non_snake_case` lint needed
to change the way it looked for parent nodes in a struct pattern.
This also includes a small fix to use the correct `Target` for
expression field attribute validation.
|
|
This extends the LintLevelBuilder to handle lint level attributes on
struct expression fields and pattern fields.
This also updates the early lints to honor lint levels on generic
parameters.
|
|
Attributes on struct expression fields were not being checked for
validity. This adds the fields as HIR nodes so that `CheckAttrVisitor`
can visit those nodes to check their attributes.
|
|
Attributes on pattern struct fields were not being checked for validity.
This adds the fields as HIR nodes so that the `CheckAttrVisitor` can
visit those nodes to check their attributes.
|
|
Do not manually craft a span pointing inside a multibyte character.
Fixes https://github.com/rust-lang/rust/issues/92462
|
|
|
|
|
|
|
|
Warn about dead tuple struct fields
Continuation of #92972. Fixes #92790.
The language team has already commented on this in https://github.com/rust-lang/rust/pull/92972#issuecomment-1021511970; I have incorporated their requests here. Specifically, there is now a new allow-by-default `unused_tuple_struct_fields` lint (name bikesheddable), and fields of unit type are ignored (https://github.com/rust-lang/rust/pull/92972#issuecomment-1021815408), so error messages look like this:
```
error: field is never read: `1`
--> $DIR/tuple-struct-field.rs:6:21
|
LL | struct Wrapper(i32, [u8; LEN], String);
| ^^^^^^^^^
|
help: change the field to unit type to suppress this warning while preserving the field numbering
|
LL | struct Wrapper(i32, (), String);
| ~~
```
r? `@joshtriplett`
|
|
Currently, the let_underscore_lock lint simply tells what is wrong, but
not why it is wrong. We fix this by using a `MultiSpan` to explain
specifically that doing `let _ = ` immediately drops the lock guard
because it does not assign the lock guard to a binding.
|
|
r=petrochenkov
Enable unused_parens for match arms
Fixes: https://github.com/rust-lang/rust/issues/92751
Currently I can't get the `stderr` to work with `./x.py test`, but this should fix the issue. Help would be appreciated!
|
|
|
|
Prevent ICE for `doc_alias` on match arm, statement, expression
Fixes #99777.
This is a pretty minimal fix that should be safe, since rustdoc doesn't generate documentation for match arms, statements, or expressions. I mentioned in the linked issue that the `doc_alias` target checking should probably be improved to avoid future ICEs, but as a new contributor, I'm not confident enough with the HIR types to make a larger change.
|
|
fix is_disaligned logic for nested packed structs
https://github.com/rust-lang/rust/pull/83605 broke the `is_disaligned` logic by bailing out of the loop in `is_within_packed` early. This PR fixes that problem and adds suitable tests.
Fixes https://github.com/rust-lang/rust/issues/99838
|
|
|
|
|
|
- Added `Impl`, `Closure`, ForeignMod` targets
- `Target::name` changed for `Target::Impl`
- Error output for `Target::ForeignMod` changed to "foreign module"
|
|
|
|
|
|
|
|
|
|
|
|
Logarithmus:feature/99255-omit-const-generic-suffixes, r=petrochenkov
feat: omit suffixes in const generics (e.g. `1_i32`)
Closes #99255
|
|
Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations
Currently, the `#[derive]` attribute always injects an `#[allow(unused_qualifications)]` attribute in the generated implementation. This results in an error when a derive is used in combination with `#![forbid(unused_qualifications)]`, because the `forbid` rule by definition cannot be overridden by `allow`.
It appears that the original issue that prompted the inclusion of `#[allow(unused_qualifications)]` (#19102) is no longer present in the current stable release, and the associated [test case](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-19102.rs) still passes, so the `allow` is simply removed here.
Fixes #71898.
|
|
Currently `#![forbid(unused_qualifications)]` is incompatible with all
derive's because we add `#[allow(unused_qualifications)]` in all
generated impl's.
|
|
Closes #99255
|
|
The restriction that success ordering must be at least as strong as its
failure ordering in compare-exchange operations was lifted in #98383.
|
|
|
|
Support unstable moves via stable in unstable items
part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of https://github.com/rust-lang/rust/pull/90328.
The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge.
This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.
|
|
`UnsafeCell` blocks niches inside its nested type from being available outside
fixes #87341
This implements the plan by `@eddyb` in https://github.com/rust-lang/rust/issues/87341#issuecomment-886083646
Somewhat related PR (not strictly necessary, but that cleanup made this PR simpler): #94527
|
|
|
|
|
|
|
|
|
