Commit Graph

192 Commits

Author SHA1 Message Date
Matthias Krüger
308ea7120b
Rollup merge of #135860 - fmease:compiler-mv-obj-save-dyn-compat-ii, r=jieyouxu
Compiler: Finalize dyn compatibility renaming

Update the Reference link to use the new URL fragment from https://github.com/rust-lang/reference/pull/1666 (this change has finally hit stable). Fixes a FIXME.

Follow-up to #130826.
Part of #130852.

~~Blocking it on #133372.~~ (merged)

r? ghost
2025-01-31 12:28:15 +01:00
Michael Goulet
7e68422859 Properly check that array length is valid type during built-in unsizing in index 2025-01-28 17:52:28 +00:00
León Orell Valerian Liehr
57b5d3af62
Compiler: Finalize dyn compatibility renaming 2025-01-26 21:20:31 +01:00
bors
a30f9151fe Auto merge of #135896 - matthiaskrgr:rollup-g6rv7za, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #132983 (Edit dangling pointers )
 - #135409 (Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block)
 - #135557 (Point at invalid utf-8 span on user's source code)
 - #135596 (Properly note when query stack is being cut off)
 - #135794 (Detect missing fields with default values and suggest `..`)
 - #135814 (ci: use ghcr buildkit image)
 - #135826 (Misc. `rustc_resolve` cleanups)
 - #135837 (Remove test panic from File::open)
 - #135856 (Library: Finalize dyn compatibility renaming)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-22 22:19:08 +00:00
Taylor Cramer
d00d4dfe0d Refactor dyn-compatibility error and suggestions
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there
  exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability

Additionally, the dyn compatibility error creation code has been
split out into functions.

cc #132713
cc #133267
2025-01-22 09:20:57 -08:00
Michael Goulet
be56f10a69 Properly note when query stack is being cut off 2025-01-16 19:12:22 +00:00
Michael Goulet
85c9ce6d79 Remove a bunch of diagnostic stashing that doesn't do anything 2025-01-11 19:22:06 +00:00
Oli Scherer
07fcead073 Always take the Ok path in lit_to_const and produce error constants instead 2025-01-09 08:48:00 +00:00
John Kåre Alsaker
4bf85c25ec Try to write the panic message with a single write_all call 2025-01-01 15:58:29 +01:00
Zalathar
835fbcbcab Remove the -test suffix from normalize directives 2024-12-27 19:58:16 +11:00
lcnr
f0ae48d106 add tests 2024-12-18 16:35:06 +01:00
Ralf Jung
ed8ee39930 fix ICE on type error in promoted 2024-12-09 15:17:26 +01:00
Ben Kimock
711c8cc690 Remove polymorphization 2024-12-06 16:42:09 -05:00
Ralf Jung
a17294dc0f fix ICE when promoted has layout size overflow 2024-12-01 19:52:27 +01:00
Matthias Krüger
5d0ee56e88
Rollup merge of #133518 - compiler-errors:structurally-resolve-never, r=lcnr
Structurally resolve before checking `!` in HIR typeck

Some more missing structural resolves in HIR typeck :>

r? lcnr
2024-11-27 22:23:26 +01:00
Michael Goulet
4c0ea55f40 Bless tests due to extra error reporting due to normalizing types that are not WF
It's okay though b/c these are duplicated diagnostics.
2024-11-27 03:34:58 +00:00
Michael Goulet
82622c6876
Rollup merge of #133471 - lcnr:uwu-gamer, r=BoxyUwU
gce: fix typing_mode mismatch

Fixes #133271

r? `@BoxyUwU`
2024-11-26 20:35:39 -05:00
lcnr
58936c1d2a fix gce typing_mode mismatch 2024-11-25 19:58:12 +01:00
Michael Goulet
28970a2cb0 Simplify array length mismatch error reporting 2024-11-24 03:32:11 +00:00
Michael Goulet
0465f71d60 Stop being so bail-y in candidate assembly 2024-11-21 01:35:34 +00:00
Boxy
bea0148ac6 Consolidate type system const evaluation under traits::evaluate_const
mew
2024-11-12 02:54:03 +00:00
Michael Goulet
0b5ddf30eb Yeet effects feature 2024-11-03 18:59:31 +00:00
Esteban Küber
5b54286640 Remove detail from label/note that is already available in other note
Remove the "which is required by `{root_obligation}`" post-script in
"the trait `X` is not implemented for `Y`" explanation in E0277. This
information is already conveyed in the notes explaining requirements,
making it redundant while making the text (particularly in labels)
harder to read.

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
vs the prior

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
2024-10-29 16:26:57 +00:00
Deadbeef
f2f67232a5 Deny calls to non-#[const_trait] methods in MIR constck 2024-10-26 11:35:56 +08:00
lcnr
1a9d2d82a5 stabilize -Znext-solver=coherence 2024-10-15 13:11:00 +02:00
VulnBandit
9a2772e1c2 Don't assume traits used as type are trait objs 2024-10-11 17:36:04 +02:00
León Orell Valerian Liehr
20cebae312
UI tests: Rename "object safe" to "dyn compatible" 2024-10-10 01:13:29 +02:00
Barrett Ray
c5598d6a9e fix(hir_analysis/wfcheck): don't leak {type error}
avoid `{type error}` being leaked in user-facing messages,
particularly when using the `adt_const_params` feature
2024-09-29 23:40:43 -05:00
Matthias Krüger
a935064fae
Rollup merge of #130826 - fmease:compiler-mv-obj-safe-dyn-compat, r=compiler-errors
Compiler: Rename "object safe" to "dyn compatible"

Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118.
Tracking issue: https://github.com/rust-lang/rust/issues/130852

Excludes `compiler/rustc_codegen_cranelift` (to be filed separately).
Includes Stable MIR.

Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language).

r? ghost
2024-09-27 21:35:08 +02:00
León Orell Valerian Liehr
01a063f9df
Compiler: Rename "object safe" to "dyn compatible" 2024-09-25 13:26:48 +02:00
Michael Goulet
ead569a06d Ban combination of GCE and new solver 2024-09-24 10:53:32 -04:00
Michael Goulet
3b8089a320 Introduce structurally_normalize_const, use it in hir_typeck 2024-09-22 13:54:16 -04:00
Michael Goulet
a9a8f79f86 Normalize unevaluated consts in GCE 2024-09-20 20:24:22 -04:00
Santiago Pastorino
65f8999026
Remove redundant test typeid equality by subtyping 2024-09-17 15:45:15 -03:00
Noah Lev
e0bd01167e Re-enable ConstArgKind::Path lowering by default
...and remove the `const_arg_path` feature gate as a result. It was only
a stopgap measure to fix the regression that the new lowering introduced
(which should now be fixed by this PR).
2024-09-12 13:56:01 -04:00
Michael Goulet
e866f8a97d Revert 'Stabilize -Znext-solver=coherence' 2024-09-11 17:57:04 -04:00
lcnr
1a893ac648 stabilize -Znext-solver=coherence 2024-09-05 07:57:16 +00:00
Matthias Krüger
c0bedb9e5e
Rollup merge of #129246 - BoxyUwU:feature_gate_const_arg_path, r=cjgillot
Retroactively feature gate `ConstArgKind::Path`

This puts the lowering introduced by #125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :)

cc #129137 ``@camelid,`` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta.

Fixes #128016
2024-08-24 22:14:12 +02:00
Boxy
b8eedfa3d2 Retroactively feature gate ConstArgKind::Path 2024-08-19 01:14:22 +01:00
Michael Goulet
84044cd50f Bless test fallout 2024-08-17 12:43:25 -04:00
bors
19469cb536 Auto merge of #128714 - camelid:wf-struct-exprs, r=BoxyUwU
WF-check struct field types at construction site

Fixes #126272.
Fixes #127299.

Rustc of course already WF-checked the field types at the definition
site, but for error tainting of consts to work properly, there needs to
be an error emitted at the use site. Previously, with no use-site error,
we proceeded with CTFE and ran into ICEs since we are running code with
type errors.

Emitting use-site errors also brings struct-like constructors more in
line with fn-like constructors since they already emit use-site errors
for WF issues.

r? `@BoxyUwU`
2024-08-10 05:27:17 +00:00
Noah Lev
9479792cb4 WF-check struct field types at construction site
Rustc of course already WF-checked the field types at the definition
site, but for error tainting of consts to work properly, there needs to
be an error emitted at the use site. Previously, with no use-site error,
we proceeded with CTFE and ran into ICEs since we are running code with
type errors.

Emitting use-site errors also brings struct-like constructors more in
line with fn-like constructors since they already emit use-site errors
for WF issues.
2024-08-05 17:37:12 -07:00
Ralf Jung
46896d6f66 interpret: move nullary-op evaluation into operator.rs 2024-08-05 22:42:34 +02:00
Michael Goulet
ac56007ea7 Revert "Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix"
This reverts commit 13314df21b, reversing
changes made to 6e534c73c3.
2024-08-03 07:57:31 -04:00
Esteban Küber
8ce8c42e0b Do not underline suggestions for code that is already there
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.

Fix clippy lint suggestion incorrectly treated as `span_help`.
2024-08-01 18:53:42 +00:00
Michael Goulet
454c600004 Detect non-lifetime binder params shadowing item params 2024-07-29 14:26:21 -04:00
Trevor Gross
ceae37188b
Rollup merge of #126575 - fmease:update-lint-type_alias_bounds, r=compiler-errors
Make it crystal clear what lint `type_alias_bounds` actually signifies

This is part of my work on https://github.com/rust-lang/rust/labels/F-lazy_type_alias ([tracking issue](#112792)).

---

To recap, the lint `type_alias_bounds` detects bounds on generic parameters and where clauses on (eager) type aliases. These bounds should've never been allowed because they are currently neither enforced[^1] at usage sites of type aliases nor thoroughly checked for correctness at definition sites due to the way type aliases are represented in the compiler. Allowing them was an oversight.

Explicitly label this as a known limitation of the type checker/system and establish the experimental feature `lazy_type_alias` as its eventual proper solution.

Where this becomes a bit tricky (for me as a rustc dev) are the "secondary effects" of these bounds whose existence I sadly can't deny. As a matter of fact, type alias bounds do play some small roles during type checking. However, after a lot of thinking over the last two weeks I've come to the conclusion (not without second-guessing myself though) that these use cases should not trump the fact that these bounds are currently *inherently broken*. Therefore the lint `type_alias_bounds` should and will continue to flag bounds that may have subordinate uses.

The two *known* secondary effects are:

1. They may enable the use of "shorthand" associated type paths `T::Assoc` (as opposed to fully qualified paths `<T as Trait>::Assoc`) where `T` is a type param bounded by some trait `Trait` which defines that assoc ty.
2. They may affect the default lifetime of trait object types passed as a type argument to the type alias. That concept is called (trait) object lifetime default.

The second one is negligible, no question asked. The first one however is actually "kinda nice" (for writability) and comes up in practice from time to time.

So why don't I just special-case trait bounds that "define" shorthand assoc type paths as originally planned in #125709?

1. Starting to permit even a tiny subset of bounds would already be enough to send a signal to users that bounds in type aliases have been legitimized and that they can expect to see type alias bounds in the wild from now on (proliferation). This would be actively misleading and dangerous because those bounds don't behave at all like one would expect, they are *not real*[^2]!
   1. Let's take `type A<T: Trait> = T::Proj;` for example. Everywhere else in the language `T: Trait` means `T: Trait + Sized`. For type aliases, that's not the case though: `T: Trait` and `T: Trait + ?Sized` for that matter do neither mean `T: Trait + Sized` nor `T: Trait + ?Sized` (for both!). Instead, whether `T` requires `Sized` or not entirely depends on the definition of `Trait`[^2]. Namely, whether or not it is bounded by `Sized`.
   2. Given `type A<T: Trait<AssocA = ()>> = T::AssocB;`, while `X: Trait` gets checked given `A<X>` (by virtue of projection wfchecking post alias expansion[^2]), the associated type constraint `AssocA = ()` gets dropped entirely! While we could choose to warn on such cases, it would inevitably lead to a huge pile of special cases.
   3. While it's common knowledge that the body / aliased type / RHS of an (eager) type alias does not get checked for well-formedness, I'm not sure if people would realize that that extends to bounds as well. Namely, `type A<T: Trait<[u8]>> = T::Proj;` compiles even if `Trait`'s generic parameter requires `Sized`. Of course, at usage sites `[u8]: Sized` would still end up getting checked[^2], so it's not a huge problem if you have full control over `A`. However, imagine that `A` was actually part of a public API and was never used inside the defining crate (not unreasonable). In such a scenario, downstream users would be presented with an impossible to use type alias! Remember, bounds may grow arbitrarily complex and nuanced in practice.
   4. Even if we allowed trait bounds that "define" shorthand assoc type paths, we would still need to continue to warn in cases where the assoc ty comes from a supertrait despite the fact that the shorthand syntax can be used: `type A<T: Sub> = T::Assoc;` does compile given `trait Sub: Super {}` and `trait Super { type Assoc; }`. However, `A<X>` does not enforce `X: Sub`, only `X: Super`[^2]. All that to say, type alias bounds are simply not real and we shouldn't pretend they are!
   5. Summarizing the points above, we would be legitimizing bounds that are completely broken!
2. It's infeasible to implement: Due to the lack of `TypeckResults` in `ItemCtxt` (and a way to propagate it to other parts of the compiler), the resolution of type-dependent paths in non-`Body` items (most notably type aliases) is not recoverable from the HIR alone which would be necessary because the information of whether an associated type path (projection) is a shorthand is only present pre&in-HIR and doesn't survive HIR ty lowering. Of course, I could rerun parts of HIR ty lowering inside the lint `type_alias_bounds` (namely, `probe_single_ty_param_bound_for_assoc_ty` which would need to be exposed or alternatively a stripped-down version of it). This likely has a performance impact and introduces complexity. In short, the "benefits" are not worth the costs.

---

* 3rd commit: Update a diagnostic to avoid suggesting type alias bounds
* 4th commit: Flag type alias bounds even if the RHS contains inherent associated types.
  * I started to allow them at some point in the past which was not correct (see commit for details)
* 5th commit: Allow type alias bounds if the RHS contains const projections and GCEs are enabled
  * (and add a `FIXME(generic_const_exprs)` to be revisited before (M)GCE's stabilization)
  * As a matter of fact type alias bounds are enforced in this case because the contained AnonConsts do get checked for well-formedness and crucially they inherit the generics and predicates of their parent item (here: the type alias)
* Remaining commits: Improve the lint `type_alias_bounds` itself

---

Fixes #125789 (sugg diag fix).
Fixes #125709 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #104918 (sugg diag applic fix).
Fixes #100270 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #94398 (true fix).

r? `@compiler-errors` `@oli-obk`

[^1]: From the perspective of the trait solver.
[^2]: Given `type A<T: Trait> = T::Proj;`, the reason why the trait bound "`T: Trait`" gets *seemingly* enforced at usage sites of the type alias `A` is simply because `A<X>` gets expanded to "`<X as Trait>::Proj`" very early on and it's the *expansion* that gets checked for well-formedness, not the type alias reference.
2024-07-26 02:20:28 -04:00
León Orell Valerian Liehr
a8b3dfd253
Suppress lint type_alias_bounds for ty aliases containing const projections under GCE 2024-07-23 01:26:26 +02:00
Esteban Küber
921de9d8ea Revert suggestion verbosity change 2024-07-22 22:51:53 +00:00
Esteban Küber
b30fdec5fb On generic and lifetime removal suggestion, do not leave behind stray , 2024-07-22 22:04:49 +00:00