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
`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.
Require EIIs to be defined when we compile a rust dylib
The linker will complain about undefined symbols otherwise and on object file formats with two level namespaces (Mach-O and PE/COFF) it is required to know which dylib a symbol will be imported from when linking a dylib or executable.
r? @jdonszelmann
The linker will complain about undefined symbols otherwise and on object
file formats with two level namespaces (Mach-O and PE/COFF) it is
required to know which dylib a symbol will be imported from when linking
a dylib or executable.
`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.
The name is misleading because the field contains a `Level` *and* an
`Option<LintExpectationId>`. This commit renames it `level_plus` which
better communicates that it's more than just a level.
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.
Refactor `CheckAttrVisitor` so rustfmt can format it.
I don’t have any need for this myself, but [I heard it was annoying people](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/.60.23.5Bdiagnostic.3A.3Aon_unimplemented.5D.60.20on.20trait.20methods.3F/near/594113991) and I like fixing formatting and structure problems.
The key change is that the do-nothing cases are now individual match arms instead of an enormous or-pattern. In order to achieve this cleanly, I moved the code handling `Attribute::Parsed` into a separate function matching `AttributeKind`s rather than `Attribute`s.
This also fixes `RustcAllowIncoherentImpl` being non-alphabetical because it was spelled without a leading “|” (though that by itself could be achieved by adding the optional leading “|”).
The key change is that the do-nothing cases are now individual
match arms instead of an enormous or-pattern. In order to achieve this
cleanly, I moved the code handling `Attribute::Parsed` into a separate
function matching `AttributeKind`s rather than `Attribute`s.
This also fixes `RustcAllowIncoherentImpl` being non-alphabetical
because it was spelled without a leading “|”.
Lint unused pub items in binary crates
~~This PR adds a new unstable flag -Ztreat-pub-as-pub-crate as [@Kobzol](https://github.com/Kobzol) suggested.~~
~~When compiling binary crates with this flag, the seed worklist will only contain the entry fn and won't contain other reachable items. Then we can do the dead code analysis for pub items just like they are pub(crate).~~
Related zulip thread [#general > pub/pub(crate) within a binary is a footgun](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/pub.2Fpub.28crate.29.20within.20a.20binary.20is.20a.20footgun/with/558931034).
---
Updated:
Adds a new lint `unused_pub_items_in_binary` (crate-level, default allow for now) instead of the previous unstable flag to lint unused `pub` items for binary crates.
See more details of implementation in https://github.com/rust-lang/rust/pull/149509#issuecomment-4102337689.
This lint is allowed by default, but I believe this has been better than the unstable flag. Making it warn-by-default will lead to a lot of noise for this PR (like bless many tests). So I'd like to make it warn-by-default in a separate PR in the future.
change the type of the argument of `drop_in_place` lang item to `&mut _`
We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack:
https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392
This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf.
This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`:
https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833
------
The rest of the PR is blessing tests and cleaning up things which are not necessary after this change.
One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that?
I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper)
-------
cc @RalfJung
Closes https://github.com/rust-lang/rust/issues/154274
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.
Move diagnostic attribute target checks from check_attr
Move diagnostic attribute target checks into their targets. Part of https://github.com/rust-lang/rust/issues/131229#issuecomment-3959910413
This is much easier with `emit_dyn_lint` :) (thanks @GuillaumeGomez !)
I think there might be some opportunity to simplify all these `check_diagnostic_*` methods in `check_attr`. However there are some diagnostic attribute prs in flight and I'd like to wait for those to land first and then think about it. So that PR is not for today.
r? @JonathanBrouwer (or @GuillaumeGomez if you want)
Fix `#[expect(dead_code)]` liveness propagation
Fixes https://github.com/rust-lang/rust/issues/154324
Fixes https://github.com/rust-lang/rust/issues/152370 (cc @eggyal)
Previously, when traversing from a `ComesFromAllowExpect::Yes` item (i.e., with `#[allow(dead_code)]` or `#[expect(dead_code)]`), other `ComesFromAllowExpect::Yes` items reached during propagation would be updated to `ComesFromAllowExpect::No` and inserted into `live_symbols`. That caused `dead_code` lint couldn't be emitted correctly.
After this PR, `ComesFromAllowExpect::Yes` items no longer incorrectly update other `ComesFromAllowExpect::Yes` items during propagation or mark them live by mistake, then `dead_code` lint could behave as expected.
Refactor FnDecl and FnSig non-type fields into a new wrapper type
#### Why this Refactor?
This PR is part of an initial cleanup for the [arg splat experiment](https://github.com/rust-lang/rust/issues/153629), but it's a useful refactor by itself.
It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR:
https://github.com/rust-lang/rust/pull/153697#discussion_r3004637413
It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults.
#### Relationship to `splat` Experiment
I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment.
Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added.
This PR packs these types:
- ExternAbi: enum + `unwind` variants (38) -> 6 bits
- ImplicitSelfKind: enum variants (5) -> 3 bits
- lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit
#### Minor Changes
Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.
Post-attribute ports cleanup pt. 1 (again)
This is a re-implementation of most (but not all) of https://github.com/rust-lang/rust/pull/154808
The code is the same as in that PR, other than a few changes, I'll leave comments where I changed things.
I did re-implement most of the commits rather than cherry-picking, so it's probably good to check the entire diff regardless
r? @jdonszelmann
Jonathan Brouwer