Commit Graph

4271 Commits

Author SHA1 Message Date
Bryanskiy
34fcf92ea0 Add special-case for [T, 0] in dropck 2024-07-31 16:15:05 +03:00
bohan
97469cc4bf only accept adt type during infer source visitor 2024-07-29 22:29:34 +08:00
Nicholas Nethercote
84ac80f192 Reformat use declarations.
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
2024-07-29 08:26:52 +10:00
Trevor Gross
bd18f88dab
Rollup merge of #128201 - compiler-errors:closure-clone, r=oli-obk
Implement `Copy`/`Clone` for async closures

We can do so in the same cases that regular closures do.

For the purposes of cloning, coroutine-closures are actually precisely the same as regular closures, specifically in the aspect that `Clone` impls care about which is the upvars. The only difference b/w coroutine-closures and regular closures is the type that they *return*, but this type has not been *created* yet, so we don't really have a problem.

IDK why I didn't add this impl initially -- I went back and forth a bit on the internal representation for coroutine-closures before settling on a design which largely models regular closures. Previous (not published) iterations of coroutine-closures used to be represented as a special (read: cursed) kind of coroutine, which would probably suffer from the pitfalls that coroutines have that oli mentioned below in https://github.com/rust-lang/rust/pull/128201#issuecomment-2251230274.

r? oli-obk
2024-07-26 19:03:05 -04:00
bors
7c2012d0ec Auto merge of #121676 - Bryanskiy:polarity, r=petrochenkov
Support ?Trait bounds in supertraits and dyn Trait under a feature gate

This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example:
```rust
#![feature(allow_maybe_polarity)]
...
trait Trait1 : ?Trait { ... } // ok
fn foo(_: Box<(dyn Trait2 + ?Trait)>) {} // ok
fn bar<T: ?Sized + ?Trait>(_: &T) {} // ok
```
Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762).

This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727)
2024-07-26 20:14:16 +00:00
Michael Goulet
d5656059a1 Make coroutine-closures possible to be cloned 2024-07-26 12:53:53 -04:00
Matthias Krüger
a88354831b
Rollup merge of #126090 - compiler-errors:supertrait-assoc-ty-unsoundness, r=lcnr
Fix supertrait associated type unsoundness

### What?

Object safety allows us to name `Self::Assoc` associated types in certain positions if they come from our trait or one of our supertraits. When this check was implemented, I think it failed to consider that supertraits can have different args, and it was only checking def-id equality.

This is problematic, since we can sneak different implementations in by implementing `Supertrait<NotActuallyTheSupertraitSubsts>` for a `dyn` type. This can be used to implement an unsound transmute function. See the committed test.

### How do we fix it?

We consider the whole trait ref when checking for supertraits. Right now, this is implemented using equality *without* normalization. We erase regions since those don't affect trait selection.

This is a limitation that could theoretically affect code that should be accepted, but doesn't matter in practice -- there are 0 crater regression. We could make this check stronger, but I would be worried about cycle issues. I assume that most people are writing `Self::Assoc` so they don't really care about the trait ref being normalized.

---

### What is up w the stacked commit

This is built on top of https://github.com/rust-lang/rust/pull/122804 though that's really not related, it's just easier to make this modification with the changes to the object safety code that I did in that PR. The only thing is that PR may make this unsoundness slightly easier to abuse, since there are more positions that allow self-associated-types -- I am happy to stall that change until this PR merges.

---

Fixes #126079

r? lcnr
2024-07-26 00:57:20 +02:00
Bryanskiy
2a73553513 Support ?Trait bounds in supertraits and dyn Trait under a feature gate 2024-07-25 20:53:33 +03:00
Matthias Krüger
1fda084290
Rollup merge of #128160 - compiler-errors:auto, r=jackh726
Don't ICE when auto trait has assoc ty in old solver

Kinda a pointless change to make, but it's observable w/o the feature gate, so let's just fix it. I reintroduced this ICE when I removed the "auto impl" kind from `ImplSource` in #112687.

Fixes #117829
Fixes #127746
2024-07-25 04:43:20 +02:00
Michael Goulet
0919d0714e Don't ICE when auto trait has assoc ty in old solver 2024-07-24 17:19:44 -04:00
Oli Scherer
8ea461da55 Do not assemble candidates for auto traits of opaque types in their defining scope 2024-07-24 16:00:48 +00:00
Oli Scherer
acba6449f8 Do not try to reveal hidden types when trying to prove Freeze in the defining scope 2024-07-24 16:00:48 +00:00
Oli Scherer
61b5e11c47 Don't use global caches if opaques can be defined 2024-07-24 10:45:21 +00:00
Matthias Krüger
004d1adc5d
Rollup merge of #128076 - compiler-errors:infer_ctxt_ext, r=lcnr
Get rid of `InferCtxtExt` from `error_reporting::traits`

One more cleanup.

r? lcnr
2024-07-23 13:06:56 +02:00
Michael Goulet
6310e40578 Get rid of infer_ctxt_ext 2024-07-22 16:15:52 -04:00
Michael Goulet
7bca516b35 Get rid of can_eq_shallow 2024-07-22 13:54:48 -04:00
Michael Goulet
e9e9495f21 Fix tools 2024-07-21 22:34:37 -04:00
Michael Goulet
ce8a625092 Move all error reporting into rustc_trait_selection 2024-07-21 22:34:35 -04:00
Michael Goulet
f49738ba6c Move need_type_info too 2024-07-21 22:33:15 -04:00
bors
9629b90b3f Auto merge of #127722 - BoxyUwU:new_adt_const_params_limitations, r=compiler-errors
Forbid borrows and unsized types from being used as the type of a const generic under `adt_const_params`

Fixes #112219
Fixes #112124
Fixes #112125

### Motivation

Currently the `adt_const_params` feature allows writing `Foo<const N: [u8]>` this is entirely useless as it is not possible to write an expression which evaluates to a type that is not `Sized`. In order to actually use unsized types in const generics they are typically written as `const N: &[u8]` which *is* possible to provide a value of.

Unfortunately allowing the types of const parameters to contain references is non trivial (#120961) as it introduces a number of difficult questions about how equality of references in the type system should behave. References in the types of const generics is largely only useful for using unsized types in const generics.

This PR introduces a new feature gate `unsized_const_parameters` and moves support for `const N: [u8]` and `const N: &...` from `adt_const_params` into it. The goal here hopefully is to experiment with allowing `const N: [u8]` to work without references and then eventually completely forbid references in const generics.

Splitting this out into a new feature gate means that stabilization of `adt_const_params` does not have to resolve #120961 which is the only remaining "big" blocker for the feature. Remaining issues after this are a few ICEs and naming bikeshed for `ConstParamTy`.

### Implementation

The implementation is slightly subtle here as we would like to ensure that a stabilization of `adt_const_params` is forwards compatible with any outcome of `unsized_const_parameters`. This is inherently tricky as we do not support unstable trait implementations and we determine whether a type is valid as the type of a const parameter via a trait bound.

There are a few constraints here:
- We would like to *allow for the possibility* of adding a `Sized` supertrait to `ConstParamTy` in the event that we wind up opting to not support unsized types and instead requiring people to write the 'sized version', e.g. `const N: [u8; M]` instead of `const N: [u8]`.
- Crates should be able to enable `unsized_const_parameters` and write trait implementations of `ConstParamTy` for `!Sized` types without downstream crates that only enable `adt_const_params` being able to observe this (required for std to be able to `impl<T> ConstParamTy for [T]`

Ultimately the way this is accomplished is via having two traits (sad), `ConstParamTy` and `UnsizedConstParamTy`. Depending on whether `unsized_const_parameters` is enabled or not we change which trait is used to check whether a type is allowed to be a const parameter.

Long term (when stabilizing `UnsizedConstParamTy`) it should be possible to completely merge these traits (and derive macros), only having a single `trait ConstParamTy` and `macro ConstParamTy`.

Under `adt_const_params` it is now illegal to directly refer to `ConstParamTy` it is only used as an internal impl detail by `derive(ConstParamTy)` and checking const parameters are well formed. This is necessary in order to ensure forwards compatibility with all possible future directions for `feature(unsized_const_parameters)`.

Generally the intuition here should be that `ConstParamTy` is the stable trait that everything uses, and `UnsizedConstParamTy` is that plus unstable implementations (well, I suppose `ConstParamTy` isn't stable yet :P).
2024-07-21 05:36:21 +00:00
Matthias Krüger
89798e9064
Rollup merge of #127987 - estebank:impl-trait-sugg, r=cjgillot
More accurate suggestion for `-> Box<dyn Trait>` or `-> impl Trait`

When encountering `-> Trait`, suggest `-> Box<dyn Trait>` (instead of `-> Box<Trait>`.

If there's a single returned type within the `fn`, suggest `-> impl Trait`.
2024-07-20 07:13:46 +02:00
Esteban Küber
3ff758877f More accurate suggestion for -> Box<dyn Trait> or -> impl Trait
When encountering `-> Trait`, suggest `-> Box<dyn Trait>` (instead of `-> Box<Trait>`.

If there's a single returned type within the `fn`, suggest `-> impl Trait`.
2024-07-19 19:39:37 +00:00
Matthias Krüger
9f8c618a90
Rollup merge of #127856 - RalfJung:interpret-cast-sanity, r=oli-obk
interpret: add sanity check in dyn upcast to double-check what codegen does

For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.)

This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path.

r? ``@oli-obk``
2024-07-19 17:06:50 +02:00
bors
8c3a94a1c7 Auto merge of #125915 - camelid:const-arg-refactor, r=BoxyUwU
Represent type-level consts with new-and-improved `hir::ConstArg`

### Summary

This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:

- Add `current_def_id_parent` to `LoweringContext`

  This is needed to track anon const parents properly once we implement
  `ConstArgKind::Path` (which requires moving anon const def-creation
  outside of `DefCollector`).

- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
  existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.

- Use `ConstArg` for all instances of const args. Specifically, use it instead
  of `AnonConst` for assoc item constraints, array lengths, and const param
  defaults.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.

### Followup items post-merge

- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
  instead (do this in rustc_resolve). Then remove the special-casing from
  `rustc_ast_lowering`, so that all params will automatically be lowered as
  `ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
  trying it in crater

r? `@BoxyUwU`
2024-07-19 08:44:51 +00:00
Michael Goulet
8dbb63a585 Remove tag field from relations 2024-07-18 14:34:05 -04:00
Ralf Jung
e613bc92a1 const_to_pat: cleanup leftovers from when we had to deal with non-structural constants 2024-07-18 11:58:16 +02:00
Ralf Jung
fa74a9e6aa valtree construction: keep track of which type was valtree-incompatible 2024-07-18 11:58:16 +02:00
Ralf Jung
a7b80819e9 interpret: add sanity check in dyn upcast to double-check what codegen does 2024-07-18 11:41:10 +02:00
Michael Goulet
0b5ce54bc2 Fix relations 2024-07-17 10:46:10 -04:00
Boxy
d0c11bf6e3 Split part of adt_const_params into unsized_const_params 2024-07-17 11:01:29 +01:00
Boxy
42cc42b942 Forbid !Sized types and references 2024-07-17 11:01:29 +01:00
Noah Lev
37ed7a4438 Add ConstArgKind::Path and make ConstArg its own HIR node
This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:

- `ConstArgKind` gets a new `Path` variant, and all const params are now
  represented using it. Non-param paths still use `ConstArgKind::Anon`
  to prevent this change from getting too large, but they will soon use
  the `Path` variant too.

- `ConstArg` gets a distinct `hir_id` field and its own variant in
  `hir::Node`. This affected many parts of the compiler that expected
  the parent of an `AnonConst` to be the containing context (e.g., an
  array repeat expression). They have been changed to check the
  "grandparent" where necessary.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at #127009.
2024-07-16 19:27:28 -07:00
Trevor Gross
059222ddc9
Rollup merge of #127501 - compiler-errors:invert-infer-error-mod-struture, r=lcnr
Invert infer `error_reporting` mod struture

Parallel change to #127493, which moves `rustc_infer::infer::error_reporting` to `rustc_infer::error_reporting::infer`. After this, we should just be able to merge this into `rustc_trait_selection::error_reporting::infer`, and pull down `TypeErrCtxt` into that crate. 👍

r? lcnr
2024-07-16 16:15:16 -05:00
yukang
48ddf5e323 Fix the issue of invalid suggestion for a reference of iterator 2024-07-16 22:01:55 +08:00
Michael Goulet
e86fbcfd70 Move rustc_infer::infer::error_reporting to rustc_infer::error_reporting::infer 2024-07-15 20:16:12 -04:00
Michael Goulet
841b30f63e Make sure trait def ids match before zipping args in note_function_argument_obligation 2024-07-15 17:53:22 -04:00
Michael Goulet
172cf9bef3 Fix unsoundness when associated types dont actually come from supertraits 2024-07-15 14:17:32 -04:00
Michael Goulet
8edf9b8084 Item bounds can reference self projections and still be object safe 2024-07-15 14:16:48 -04:00
Jubilee
4bfc10617a
Rollup merge of #127631 - compiler-errors:yeet-fully-norm, r=lcnr
Remove `fully_normalize`

Yeet this function and replace it w/ some `ObligationCtxt` instead. It wasn't called very often anyways.

r? lcnr
2024-07-12 13:47:09 -07:00
Michael Goulet
2c8bbeebf1 Remove fully_normalize 2024-07-11 19:15:04 -04:00
Georg Semmler
27d5db166e
Allows #[diagnostic::do_not_recommend] to supress trait impls in suggestions as well
This commit changes the error reporting mechanism for not implemented
traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the
help part of the error message ("the following other types implement
trait `Foo`:"). The main use case here is to allow crate authors to skip
non-meaningful confusing suggestions. A common example for this are
fully generic impls on tuples.
2024-07-11 08:14:28 +02:00
Matthias Krüger
22df186d6f
Rollup merge of #127570 - lcnr:normalize-cool, r=compiler-errors
small normalization improvement

r? `@compiler-errors`
2024-07-10 17:54:29 +02:00
lcnr
e00fd781c9 simplify and future-proof needs_normalization 2024-07-10 15:56:20 +02:00
lcnr
f77394fdf3 instantiate higher ranked goals in candidate selection
reverts #119820
2024-07-10 14:13:16 +02:00
Michael Goulet
bbbff80603 Split out fulfillment error reporting a bit more 2024-07-09 09:57:16 -04:00
Michael Goulet
cd68a28daa Move some stuff into the ambiguity and suggestion modules 2024-07-09 09:51:56 -04:00
Michael Goulet
7af825fea4 Split out overflow handling into its own module 2024-07-09 09:51:56 -04:00
Michael Goulet
fe4c995ccb Move trait selection error reporting to its own top-level module 2024-07-08 16:04:47 -04:00
许杰友 Jieyou Xu (Joe)
ffb93361b4
Rollup merge of #127439 - compiler-errors:uplift-elaborate, r=lcnr
Uplift elaboration into `rustc_type_ir`

Allows us to deduplicate and consolidate elaboration (including these stupid elaboration duplicate fns i added for pretty printing like 3 years ago) so I'm pretty hyped about this change :3

r? lcnr
2024-07-08 13:04:33 +08:00
许杰友 Jieyou Xu (Joe)
928d71f17b
Rollup merge of #127437 - compiler-errors:uplift-trait-ref-is-knowable, r=lcnr
Uplift trait ref is knowable into `rustc_next_trait_solver`

Self-explanatory. Eliminates one more delegate method.

r? lcnr cc ``@fmease``
2024-07-08 13:04:32 +08:00