Detects manual implementations of the newly implemented
[`BinaryHeap::pop_if()`](https://github.com/rust-lang/rust/issues/151828)
in `manual_pop_if`.
I wasn't sure about how best to handle checking for the nightly feature.
Could we let people compiling with nightly know that the feature is
available even if they don't have it enabled?
changelog: [`manual_pop_if`]: detect manual implementations of
`BinaryHeap::pop_if()`
Closes: rust-lang/rust-clippy#16654
changelog: [`question_mark`]: fix suggestion-caused-error caused by
semicolon inference relying only on parent-node shape.
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
fixesrust-lang/rust-clippy#16696
changelog: [`semicolon_inside_block`]: fix false positive in `try`
blocks where moving `;` inside changes the block's return type and
causes type errors.
It is not necessary to materialize snippets into `String` objects just
to check if they contain comments for example.
changelog: none
r? @blyxyas
(for perf measurements)
The wrong `TypeckResults` was used in the fallback equality function
passed by the `match_same_arms` and `filter_map` lints. Previously,
those fallback functions had no way of using the proper `TypeckResults`.
Those (one per expression being compared) are now passed to the
registered fallback function.
Add a lint to detect when the recently added Vec::pop_if,
VecDeque::pop_front_if, and VecDeque::pop_back_if are manually
implemented.
changelog: add [`manual_pop_if`] lint
Based on rust-lang/rust-clippy#15978
This will prevent some pointless merge conflict when multiple people add
lints to the same lint pass (e.g. methods).
changelog: None
Fixrust-lang/rust-clippy#16155
Suppress the `-> !` suggestion when the loop is inside a conditional
where not all branches diverge. When every branch does diverge (e.g. `if
cond { loop {} } else { loop {} }`), the suggestion is still emitted.
changelog: [`infinite_loop`]: Fix wrong suggestion to add `-> !` when
the loop is inside a conditional branch
FIxesrust-lang/rust-clippy#16482
changelog: [`doc_paragraphs_missing_punctuation`]: fix: No longer lints
for punctuated paragraphs with a trailing emoji.
Fixes https://github.com/rust-lang/rust-clippy/pull/16605
This PR addresses the 6.2% compilation performance regression introduced
by the original `allow_unwrap_types` implementation (which natively
allocated AST strings on every `unwrap` call via `bumpalo`).
The implementation has been refactored to pre-resolve types securely
without a performance penalty:
**Pre-Resolution Cache via `LateLintPass`**: Instead of executing
`ty.to_string()` and `lookup_path_str` inside the immediate
`unwrap_expect_used` hot check for every method call encountered,
`allow-unwrap-types` configuration strings are now parsed exactly *once*
per crate compilation during the `LateLintPass::check_crate` hook in
`clippy_lints/src/methods/mod.rs`.
**`DefId` Native Storage**: The parsed `DefId` representations are
stored in-memory using highly efficient caching maps directly on the
main `Methods` struct:
- `unwrap_allowed_ids: FxHashSet<DefId>`: Allows instant O(1) lookups
for standard types.
- `unwrap_allowed_aliases: Vec<DefId>`: Tracks type aliases requiring
signature substitution checking later.
**Execution Relief**: Inside `unwrap_expect_used::check()`, string
manipulation is completely removed and `ty::Adt` checking uses
lightning-fast `.contains(&adt.did())` operations to categorically avoid
regression allocation loops. This implementation strongly parallels the
pre-resolution type-routing logic in
`clippy_config::types::create_disallowed_map` without altering the core
`clippy.toml` config requirements.
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/16652#issuecomment-3976671413)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
changelog: none
Don’t report missing fields in struct exprs with syntax errors.
@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.
Specifically, if the user writes a struct literal with a syntax error, such as
```rust
StructName { foo: 1 bar: 2 }
```
the compiler will no longer report that the field `bar` is missing in addition to the syntax error.
This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.
**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.
core: make atomic primitives type aliases of `Atomic<T>`
Tracking issue: https://github.com/rust-lang/rust/issues/130539
This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally.
Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
This adds a variant `NoneWithError` to AST and HIR representations of
the “rest” or “tail”, which is currently always treated identically to
the `None` variant.
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
add field representing types
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152730)*
> [!NOTE]
> This is a rewrite of #146307 by using a lang item instead of a custom `TyKind`. We still need a `hir::TyKind::FieldOf` variant, because resolving the field name cannot be done before HIR construction. The advantage of doing it this way is that we don't need to make any changes to types after HIR (including symbol mangling). At the very beginning of this feature implementation, I tried to do it using a lang item, but then quickly abandoned the approach, because at that time I was still intending to support nested fields.
Here is a [range-diff](https://triagebot.infra.rust-lang.org/gh-range-diff/rust-lang/rust/605f49b27444a738ea4032cb77e3bdc4eb811bab..d15f5052095b3549111854a2555dd7026b0a729e/605f49b27444a738ea4032cb77e3bdc4eb811bab..f5f42d1e03495dbaa23671c46b15fccddeb3492f) between the two PRs
---
# Add Field Representing Types (FRTs)
This PR implements the first step of the field projection lang experiment (Tracking Issue: rust-lang/rust#145383). Field representing types (FRTs) are a new kind of type. They can be named through the use of the `field_of!` macro with the first argument being the type and the second the name of the field (or variant and field in the case of an enum). No nested fields are supported.
FRTs natively implement the `Field` trait that's also added in this PR. It exposes information about the field such as the type of the field, the type of the base (i.e. the type that contains the field) and the offset within that base type. Only fields of non-packed structs are supported, fields of enums an unions have unique types for each field, but those do not implement the `Field` trait.
This PR was created in collaboration with @dingxiangfei2009, it wouldn't have been possible without him, so huge thanks for mentoring me!
I updated my library solution for field projections to use the FRTs from `core` instead of creating my own using the hash of the name of the field. See the [Rust-for-Linux/field-projection `lang-experiment` branch](https://github.com/Rust-for-Linux/field-projection/tree/lang-experiment).
## API added to `core::field`
```rust
pub unsafe trait Field {
type Base;
type Type;
const OFFSET: usize;
}
pub macro field_of($Container:ty, $($fields:expr)+ $(,)?);
```
Along with a perma-unstable type that the compiler uses in the expansion of the macro:
```rust
#[unstable(feature = "field_representing_type_raw", issue = "none")]
pub struct FieldRepresentingType<T: ?Sized, const VARIANT: u32, const FIELD: u32> {
_phantom: PhantomData<T>,
}
```
## Explanation of Field Representing Types (FRTs)
FRTs are used for compile-time & trait-level reflection for fields of structs & tuples. Each struct & tuple has a unique compiler-generated type nameable through the `field_of!` macro. This type natively contains information about the field such as the outermost container, type of the field and its offset. Users may implement additional traits on these types in order to record custom information (for example a crate may define a [`PinnableField` trait](https://github.com/Rust-for-Linux/field-projection/blob/lang-experiment/src/marker.rs#L9-L23) that records whether the field is structurally pinned).
They are the foundation of field projections, a general operation that's generic over the fields of a struct. This genericism needs to be expressible in the trait system. FRTs make this possible, since an operation generic over fields can just be a function with a generic parameter `F: Field`.
> [!NOTE]
> The approach of field projections has changed considerably since this PR was opened. In the end we might not need FRTs, so this API is highly experimental.
FRTs should act as though they were defined as `struct MyStruct_my_field<StructGenerics>;` next to the struct. So it should be local to the crate defining the struct so that one can implement any trait for the FRT from that crate. The `Field` traits should be implemented by the compiler & populated with correct information (`unsafe` code needs to be able to rely on them being correct).
## TODOs
There are some `FIXME(FRTs)` scattered around the code:
- Diagnostics for `field_of!` can be improved
- `tests/ui/field_representing_types/nonexistent.rs`
- `tests/ui/field_representing_types/non-struct.rs`
- `tests/ui/field_representing_types/offset.rs`
- `tests/ui/field_representing_types/not-field-if-packed.rs`
- `tests/ui/field_representing_types/invalid.rs`
- Simple type alias already seem to work, but might need some extra work in `compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs`
r? @oli-obk
Linshu Yang