Make impl_trait_redundant_captures suggestion remove adjacent +
Closesrust-lang/rust#143216
The `impl_trait_redundant_captures` lint's machine-applicable suggestion only
spanned the `use<...>` syntax itself, leaving the adjacent `+` joiner behind.
Applying the suggestion produced uncompilable code, e.g.
`impl Sized + use<>` becoming `impl Sized + ` (stray trailing `+`).
This extends the removal span to also cover one adjacent `+`, preserving
valid syntax in the three bound-list positions covered by the regression test:
- `impl Sized + use<>` becomes `impl Sized`
- `impl use<> + Sized` becomes `impl Sized`
- `impl Sized + use<> + Send` becomes `impl Sized + Send`
A `//@ run-rustfix` UI test exercises all three positions, so the
rustfix-applied output is actually compiled — covering the gap the
existing `redundant.rs` test left (which only checks lint firing, not
suggestion correctness).
Tested:
- ./x test tests/ui/impl-trait/precise-capturing/redundant-machine-applicable.rs --bless
- ./x test tidy
The lint suggestion now removes the `+` joiner adjacent to a redundant
`use<...>` clause, so applying the suggestion does not leave a dangling
`+` that fails to parse.
The existing `tests/ui/impl-trait/precise-capturing/redundant.stderr`
baseline emits the same diagnostic with the expanded suggestion span and
is blessed along with the new `run-rustfix` test.
Tested:
- ./x test tests/ui/impl-trait/precise-capturing/redundant.rs --force-rerun
- ./x test tests/ui/impl-trait/precise-capturing/redundant-machine-applicable.rs --force-rerun
- ./x test tidy
Remove unsound `target_feature_inline_always` feature
## Summary
- Remove `target_feature_inline_always`
- Update stdarch generators to only use `#[inline]` & regenerate stdarch.
## Why?
Succinctly; the feature relies on LLVMs `AlwaysInlinerPass()` running before LLVMs heuristic based inliner pass. Which is not a basis for sound code.
This has been discussed in [the tracking issue](https://github.com/rust-lang/rust/issues/145574).
If the ordering of the passes were to change, of which they have in the past, it is very possible we could inline functions across callsites with mismatching target features leading to unsound code. Checks proposed in; https://github.com/rust-lang/rust/pull/155426 would only take into account caller -> callee which is not enough to guard against possibly of generating unsound code if the pass ordering were to change.
There doesn't seem to be a way, presently, this this mechanism to provide soundness guarantees nor does it seem like `AlwaysInlinerPass()` is a desired feature of LLVM, which this feature relies on.
r? @RalfJung
Split `LintExpectationId`s
This PR makes clearer where stable and unstable `LintExpectationIds` can occur, plus a few other small cleanups. Details in individual commits.
r? @GuillaumeGomez
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
`LintExpectationId` has two variants, `Unstable` and `Stable`. There are
some places where both variants are possible, but there are also places
where only one of `Unstable` or `Stable` is possible.
This commit encodes this into the type system by introducing
new types `UnstableLintExpectationId` and `StableLintExpectationId`. The
variants of `LintExpectationId` now enclose these. This makes it clearer
what values are possible where.
Other things of note:
- `LintLevelsProvider` gets an associated type and some method changes.
- `LintContext` gets an associated type.
- `LevelSpec` is made generic. `UnstableLevelSpec` and `StableLevelSpec`
typedefs are added.
- The unstable types are now guaranteed by the type system to never be
stably hashed. Previously this was a runtime check.
`LevelSpec` has two related fields, `level` and `lint_id`. This commit
makes the fields private (and introduces getters) to ensure they are set
together using only valid combinations.
The commit also introduces `is_allow` and `is_expect` methods because
those are useful.
These methods return `Option<(Self, Option<LintExpectationId>)>`. But
all the call sites except one don't look at the
`Option<LintExpectationId>`.
This commit simplifies these methods to not return the
`Option<LintExpectationId>`. This means they no longer need to be passed
a closure to compute an `AttrId` (which is usually discarded anyway).
The commit also renames `from_attr` as `from_opt_symbol`, because it
takes an `Option<Symbol>`, not an `Attribute`.
These changes simplify all the call sites that don't need the
`Option<LintExpectationId>`, and also the one call site that does (in
`LintLevelsBuilder::add`): that call site no longer needs to do an
awkward destructuring, and can instead build the appropriate
`LintExpectationId` directly.
It is misnamed, given that it has three fields: `level`, `lint_id`, and
`src`. (Presumably the `lint_id` was added later.)
This commit renames it as `LevelSpec`. (I also considered `LevelInfo`
but that's very generic. `Spec` has pre-existing uses in
`LintLevelsProvider::current_specs` and `LintSet::specs` and
`ShallowLintLevelMap::specs`.)
Related things renamed as well:
- `level` -> `level_spec` (where appropriate)
- `lint_levels` -> `lint_level_specs`
- `get_lint_level` -> `get_lint_level_spec`
- `level_and_source` -> `level_spec`
- `CodegenLintLevels` -> `CodegenLintLevelSpecs`
- `raw_lint_id_level` -> `raw_lint_level_spec`
- `lint_level_at_node` -> `lint_level_spec_at_node`
- `reveal_actual_level` -> `reveal_actual_level_spec`
- `probe_for_lint_level` -> `probe_for_lint_level_spec`
This clears up a lot of `Level` vs. `LevelSpec` ambiguity. E.g. no more
`level.level` expressions.
It's currrently `(Option<(Level, Option<LintExpectationId>)>,
LintLevelSource)`. But when the first element of the pair is `None` the
second element is always `LintLevelSource::Default`. So this commit
moves the `LintLevelSource` within the `Option`, which simplifies
things a bit.
It currently returns a triple: `(Level, Option<LintExpectationId>,
LintLevelSource)`. That's structurally identical to `LevelAndSource`, so
this commit changes it accordingly.
`reveal_actual_level` has two call sites, which look like this:
```
let (level, mut src) = self.raw_lint_id_level(lint, idx, aux);
let (level, lint_id) = reveal_actual_level(level, &mut src, sess, lint, |id| {
self.raw_lint_id_level(id, idx, aux)
});
```
and:
```
let (level, mut src) = self.probe_for_lint_level(tcx, lint, cur);
let (level, lint_id) = reveal_actual_level(level, &mut src, tcx.sess, lint, |lint| {
self.probe_for_lint_level(tcx, lint, cur)
});
```
They both have the same pattern: there's a prior call expression that is then
repeated within a closure passed to `reveal_actual_level`.
This commit moves that prior call inside `reveal_actual_level`, making things
simpler.
Using https://github.com/rust-lang/rustfmt/pull/6893, reformat the codebase. The result is that matches that *would have* been formatted under normal circumstances get their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
Unnormalized migration: assert_fully_normalized, struct_tail, and `field.ty`
tracking issue: https://github.com/rust-lang/rust/issues/155345 (first checkbox, and partial second checkbox, of that issue)
I'm going a bit slower than expected (less free time than I'd hope, lots of GCA work that I'm doing instead), and figured I'd just submit what I have now rather than building up a big batch of changes. Slow and steady!
r? @lcnr
Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint
This is an extension to rust-lang/rust#147382.
With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used.
For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break.
The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent.
Fixes https://github.com/rust-lang/rust/issues/65861
fix: Guard SizeSkeleton::compute against stack overflow
Fixesrust-lang/rust#156137
Fix: extract the recursion into a private `compute_inner` that carries a depth counter. When depth exceeds the crate's recursion limit, return `LayoutError::Unknown` and let the existing transmute size-check produce a normal error instead of crashing.
A regression test is included in `tests/ui/transmute/`.
lint ImproperCTypes: refactor linting architecture (part 2)
This is the second PR in an effort to split https://github.com/rust-lang/rust/pull/134697 (refactor plus overhaul of the ImproperCTypes family of lints) into individually-mergeable parts.
Contains the changes of the first PR, and splits the core type checking function into several bits, each focused on a specific aspect of FFI-safety.
Some logic which was outside of said core function was also moved into the new functions.
Superset of: rust-lang/rust#146271
In order to follow along with the efforts to properly distinguish
already-normalised and unnormalized types, we separate the internal
interfaces of this lint that rely on normalized types from those that
do not. We do that by adding the `Unnormalized` wrapper to some
interfaces.
Move `feature*` methods from `parse` mod to `errors` mod.
As the FIXME comment says, these no longer use `ParseSess` and so the `parse` mod is not a good place for them. The `errors` mod is a better home.
r? @TaKO8Ki
It currently only depends on two things:
- `rustc_ast::AttrId`: this is just a re-export of `rustc_span::AttrId`,
so we can import the original instead.
- `rustc_ast::AttributeExt`: needed only for the `name` and `id`
methods. We can instead pass in the `name` and `id` directly.
Change `ItemKind::Trait` to a field variant.
This changes `ItemKind::Trait` from an octuple(!!) to an enum variant with fields. Their names were chosen to match up with existing usage and minimize renaming.
I'm leaning towards renaming `ident` to `name` as well; let me know if that's desired.
Remove `AttributeLintKind`
Part of https://github.com/rust-lang/rust/issues/153099.
The `AttributeLintKind` type is finally gone! \o/
Diff is this big because I moved a file and a lot of `Diagnostic` types. :')
r? @JonathanBrouwer
Create a new `SharedContext::emit_dyn_lint_with_sess` method to simplify code when `Session` is not needed
Remove crate name from `UnexpectedCfgCargoMacroHelp`
Hanna Kruppe