Currently, deriving on packed structs has some non-trivial limitations,
related to the fact that taking references on unaligned fields is UB.
The current approach to field accesses in derived code:
- Normal case: `&self.0`
- In a packed struct that derives `Copy`: `&{self.0}`
- In a packed struct that doesn't derive `Copy`: `&self.0`
Plus, we disallow deriving any builtin traits other than `Default` for any
packed generic type, because it's possible that there might be
misaligned fields. This is a fairly broad restriction.
Plus, we disallow deriving any builtin traits other than `Default` for most
packed types that don't derive `Copy`. (The exceptions are those where the
alignments inherently satisfy the packing, e.g. in a type with
`repr(packed(N))` where all the fields have alignments of `N` or less
anyway. Such types are pretty strange, because the `packed` attribute is
not having any effect.)
This commit introduces a new, simpler approach to field accesses:
- Normal case: `&self.0`
- In a packed struct: `&{self.0}`
In the latter case, this requires that all fields impl `Copy`, which is
a new restriction. This means that the following example compiles under
the old approach and doesn't compile under the new approach.
```
#[derive(Debug)]
struct NonCopy(u8);
#[derive(Debug)
#[repr(packed)]
struct MyType(NonCopy);
```
(Note that the old approach's support for cases like this was brittle.
Changing the `u8` to a `u16` would be enough to stop it working. So not
much capability is lost here.)
However, the other constraints from the old rules are removed. We can now
derive builtin traits for packed generic structs like this:
```
trait Trait { type A; }
#[derive(Hash)]
#[repr(packed)]
pub struct Foo<T: Trait>(T, T::A);
```
To allow this, we add a `T: Copy` bound in the derived impl and a `T::A:
Copy` bound in where clauses. So `T` and `T::A` must impl `Copy`.
We can now also derive builtin traits for packed structs that don't derive
`Copy`, so long as the fields impl `Copy`:
```
#[derive(Hash)]
#[repr(packed)]
pub struct Foo(u32);
```
This includes types that hand-impl `Copy` rather than deriving it, such as the
following, that show up in winapi-0.2:
```
#[derive(Clone)]
#[repr(packed)]
struct MyType(i32);
impl Copy for MyType {}
```
The new approach is simpler to understand and implement, and it avoids
the need for the `unsafe_derive_on_repr_packed` check.
One exception is required for backwards-compatibility: we allow `[u8]`
fields for now. There is a new lint for this,
`byte_slice_in_packed_struct_with_derive`.
Skip possible where_clause_object_safety lints when checking `multiple_supertrait_upcastable`
Fix#106247
To achieve this, I lifted the `WhereClauseReferencesSelf` out from `object_safety_violations` and move it into `is_object_safe` (which is changed to a new query).
cc `@dtolnay`
r? `@compiler-errors`
Remove HirId -> LocalDefId map from HIR.
Having this map in HIR prevents the creating of new definitions after HIR has been built.
Thankfully, we do not need it.
Based on https://github.com/rust-lang/rust/pull/103902
Remove overlapping parts of multipart suggestions
This PR adds a debug assertion that the parts of a single substitution cannot overlap, fixes a overlapping substitution from the testsuite, and fixes https://github.com/rust-lang/rust/issues/106870.
Note that a single suggestion can still have multiple overlapping substitutions / possible edits, we just don't suggest overlapping replacements in a single edit anymore.
I've also included a fix for an unrelated bug where rustfix for `explicit_outlives_requirements` would produce multiple trailing commas for a where clause.
use LocalDefId instead of HirId in trait resolution to simplify
the obligation clause resolution
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Switching them to `Break(())` and `Continue(())` instead.
libs-api would like to remove these constants, so stop using them in compiler to make the removal PR later smaller.
Migrate `rustc_lint` lint diagnostics
Part 2 of [Migrate `rustc_lint` errors to `SessionDiagnostic`](https://github.com/rust-lang/rust/pull/100776)
r? `@davidtwco`
# TODO
- [x] Refactor some lints manually implementing `DecorateLint` to use `Option<Subdiagnostic>`.
- [x] Add `#[rustc_lint_diagnostics]` to lint functions in `context.rs`.
- [x] Migrate `hidden_unicode_codepoints.rs`.
- [x] Migrate `UnsafeCode` in `builtin.rs`.
- [x] Migrate the rest of `builtin.rs`.
Fix stack overflow in recursive AST walk in early lint
The src/test/ui/issues/issue-74564-if-expr-stack-overflow.rs test case added to verify https://github.com/rust-lang/rust/issues/74564 still crashes with a stack overflow on s390x-ibm-linux.
Symptom is a very deep recursion in compiler/rustc_lint/src/early.rs:
fn visit_expr(&mut self, e: &'a ast::Expr) {
self.with_lint_attrs(e.id, &e.attrs, |cx| {
lint_callback!(cx, check_expr, e);
ast_visit::walk_expr(cx, e);
})
}
(where walk_expr recursively calls back into visit_expr). The crash happens at a nesting depth of over 17000 stack frames when using the default 8 MB stack size on s390x.
This patch fixes the problem by adding a ensure_sufficient_stack call to the with_lint_attrs routine (which also should take care of all the other mutually recursive visitors here).
Fixes part of https://github.com/rust-lang/rust/issues/105383.
Rename `hir::Map::{get_,find_}parent_node` to `hir::Map::{,opt_}parent_id`, and add `hir::Map::{get,find}_parent`
The `hir::Map::get_parent_node` function doesn't return a `Node`, and I think that's quite confusing. Let's rename it to something that sounds more like something that gets the parent hir id => `hir::Map::parent_id`. Same with `find_parent_node` => `opt_parent_id`.
Also, combine `hir.get(hir.parent_id(hir_id))` and similar `hir.find(hir.parent_id(hir_id))` function into new functions that actually retrieve the parent node in one call. This last commit is the only one that might need to be looked at closely.
Revert "Implement allow-by-default `multiple_supertrait_upcastable` lint"
This is a clean revert of #105484.
I confirmed that reverting that PR fixes the regression reported in #106247. ~~I can't say I understand what this code is doing, but maybe it can be re-landed with a different implementation.~~ **Edit:** https://github.com/rust-lang/rust/issues/106247#issuecomment-1367174384 has an explanation of why #105484 ends up surfacing spurious `where_clause_object_safety` errors. The implementation of `where_clause_object_safety` assumes we only check whether a trait is object safe when somebody actually uses that trait with `dyn`. However the implementation of `multiple_supertrait_upcastable` added in the problematic PR involves checking *every* trait for whether it is object-safe.
FYI `@nbdd0121` `@compiler-errors`
Implement allow-by-default `multiple_supertrait_upcastable` lint
The lint detects when an object-safe trait has multiple supertraits.
Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them.
r? `@nikomatsakis`
Switch `#[track_caller]` back to a no-op unless feature gate is enabled
This patch fixes a regression, in which `#[track_caller]`, which was previously a no-op, was changed to actually turn on the behavior. This should instead only happen behind the `closure_track_caller` feature gate.
Also, add a warning for the user to understand how their code will compile depending on the feature gate being turned on or not.
Fixes#104588
Sort lint_groups in no_lint_suggestion
The no_lint_suggestion routine passes a vector of lint group names to find_best_match_for_name. That routine depends on the sort order of its input vector, which matters in case multiple inputs are at the same Levenshtein distance to the target name.
However, no_lint_suggestion currently just passes lint_groups.keys() as input vector - this is sorted in hash value order, which is not guaranteed to be stable, and in fact differs between big- and little-endian host platforms, causing test failures on s390x.
To fix this, always sort the lint groups before using their names as input to find_best_match_for_name. In doing so, prefer non- deprecated lint group names over deprecated ones, and then use alphabetical order.
Fixes https://github.com/rust-lang/rust/issues/105379
The no_lint_suggestion routine passes a vector of lint group names
to find_best_match_for_name. That routine depends on the sort
order of its input vector, which matters in case multiple inputs
are at the same Levenshtein distance to the target name.
However, no_lint_suggestion currently just passes lint_groups.keys()
as input vector - this is sorted in hash value order, which is not
guaranteed to be stable, and in fact differs between big- and
little-endian host platforms, causing test failures on s390x.
To fix this, always sort the lint groups before using their names
as input to find_best_match_for_name. In addition, deprecated
lint groups should never be suggested, so filter those out.
Fixes https://github.com/rust-lang/rust/issues/105379
This patch does the following:
- Refactor some repeated lines into a single one
- Split the `ungated_async_fn_caller` lint into multiple lines, and make
one of those lines only print out on nightly
- Use test revisions instead of copying an existing test
This patch fixes a regression, in which `#[track_caller]`, which was
previously a no-op, was changed to actually turn on the behavior. This
should instead only happen behind the `closure_track_caller` feature
gate.
Also, add a warning for the user to understand how their code will
compile depending on the feature gate being turned on or not.
Fixes#104588
Improve syntax of `newtype_index`
This makes it more like proper Rust and also makes the implementation a lot simpler.
Mostly just turns weird flags in the body into proper attributes.
It should probably also be converted to an attribute macro instead of function-like, but that can be done in a future PR.
