remove duplicated columns from `rustc_error_code::error_codes!`
Possible because of rust-lang/rust#146308 ~~, but currently still blocked on the next stage0 bump~~.
E0793: Clarify that it applies to unions as well
pick up inactive PR: https://github.com/rust-lang/rust/pull/131472
Also:
Adjust the language slightly to be more consistent with other similar messages (was created instead of got created).
Add a short section on union.
Add an example line showing referencing a field in a packed struct is safe if the field's type isn't more strictly aligned than the pack.
r? compiler-errors
Having multiple relaxed bounds like `?Sized + ?Iterator` is actually *fine*.
We actually want to reject *duplicate* relaxed bounds like `?Sized + ?Sized`
because these most certainly represent a user error.
Note that this doesn't mean that we accept more code because a bound like
`?Iterator` is still invalid as it's not relaxing a *default* trait and
the only way to define / use more default bounds is under the experimental
and internal feature `more_maybe_bounds` plus `lang_items` plus unstable
flag `-Zexperimental-default-bounds` (historical context: for the longest
time, bounds like `?Iterator` were actually allowed and lead to a hard
warning).
Ultimately, this simply *reframes* the diagnostic. The scope of
`more_maybe_bounds` / `-Zexperimental-default-bounds` remains unchanged
as well.
The existing code produces `Some(kw::Empty)` for these invalid forms:
- a non-name-value, e.g. `#[rustc_allowed_through_unstable_modules]`
- a non-string arg, e.g. `#[rustc_allowed_through_unstable_modules = 3]`
The new code avoids the `kw::Empty` and is a little shorter. It will
produce `None` in those cases, which means E0789 won't be produced if
the `stable` attribute is missing for these invalid forms. This doesn't
matter, because these invalid forms will trigger an "malformed
`rustc_allowed_through_unstable_modules` attribute" anyway.
This clarifies the explanation of why this is not allowed and also what to do instead.
Fixes 62071
PS There was suggestion of adding a link to the book. I did not yet do that, but if desired that could be added.
Add `#[define_opaques]` attribute and require it for all type-alias-impl-trait sites that register a hidden type
Instead of relying on the signature of items to decide whether they are constraining an opaque type, the opaque types that the item constrains must be explicitly listed.
A previous version of this PR used an actual attribute, but had to keep the resolved `DefId`s in a side table.
Now we just lower to fields in the AST that have no surface syntax, instead a builtin attribute macro fills in those fields where applicable.
Note that for convenience referencing opaque types in associated types from associated methods on the same impl will not require an attribute. If that causes problems `#[defines()]` can be used to overwrite the default of searching for opaques in the signature.
One wart of this design is that closures and static items do not have generics. So since I stored the opaques in the generics of functions, consts and methods, I would need to add a custom field to closures and statics to track this information. During a T-types discussion we decided to just not do this for now.
fixes#131298
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484, reversing
changes made to c6662879b2.
By naming them in `[workspace.lints.rust]` in the top-level
`Cargo.toml`, and then making all `compiler/` crates inherit them with
`[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`,
because they're a bit different.)
The advantages of this over the current approach:
- It uses a standard Cargo feature, rather than special handling in
bootstrap. So, easier to understand, and less likely to get
accidentally broken in the future.
- It works for proc macro crates.
It's a shame it doesn't work for rustc-specific lints, as the comments
explain.
Make `ptr_cast_add_auto_to_object` lint into hard error
In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting.
We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us.
It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this.
r? ghost
cc ```@adetaylor``` ```@Darksonn``` ```@BoxyUwU``` ```@RalfJung``` ```@compiler-errors``` ```@oli-obk``` ```@WaffleLapkin```
Related:
- https://github.com/rust-lang/rust/pull/135881
- https://github.com/rust-lang/rust/issues/136702
- https://github.com/rust-lang/rust/pull/136776
Tracking:
- https://github.com/rust-lang/rust/issues/127323
- https://github.com/rust-lang/rust/issues/44874
- https://github.com/rust-lang/rust/issues/123430
Matthias Krüger