424 Commits

Author SHA1 Message Date
Matthias Krüger
ea6129084e
Rollup merge of #119354 - fmease:negative_bounds-fixes, r=compiler-errors
Make `negative_bounds` internal & fix some of its issues

r? compiler-errors
2024-01-05 20:39:51 +01:00
Michael Goulet
f41ad1bc9c
Rollup merge of #119148 - estebank:bare-traits, r=davidtwco
Tweak suggestions for bare trait used as a type

```
error[E0782]: trait objects must include the `dyn` keyword
  --> $DIR/not-on-bare-trait-2021.rs:11:11
   |
LL | fn bar(x: Foo) -> Foo {
   |           ^^^
   |
help: use a generic type parameter, constrained by the trait `Foo`
   |
LL | fn bar<T: Foo>(x: T) -> Foo {
   |       ++++++++    ~
help: you can also use `impl Foo`, but users won't be able to specify the type paramer when calling the `fn`, having to rely exclusively on type inference
   |
LL | fn bar(x: impl Foo) -> Foo {
   |           ++++
help: alternatively, use a trait object to accept any type that implements `Foo`, accessing its methods at runtime using dynamic dispatch
   |
LL | fn bar(x: &dyn Foo) -> Foo {
   |           ++++

error[E0782]: trait objects must include the `dyn` keyword
  --> $DIR/not-on-bare-trait-2021.rs:11:19
   |
LL | fn bar(x: Foo) -> Foo {
   |                   ^^^
   |
help: use `impl Foo` to return an opaque type, as long as you return a single underlying type
   |
LL | fn bar(x: Foo) -> impl Foo {
   |                   ++++
help: alternatively, you can return an owned trait object
   |
LL | fn bar(x: Foo) -> Box<dyn Foo> {
   |                   +++++++    +
```

Fix #119525:

```

error[E0038]: the trait `Ord` cannot be made into an object
  --> $DIR/bare-trait-dont-suggest-dyn.rs:3:33
   |
LL | fn ord_prefer_dot(s: String) -> Ord {
   |                                 ^^^ `Ord` cannot be made into an object
   |
note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
  --> $SRC_DIR/core/src/cmp.rs:LL:COL
   |
   = note: the trait cannot be made into an object because it uses `Self` as a type parameter
  ::: $SRC_DIR/core/src/cmp.rs:LL:COL
   |
   = note: the trait cannot be made into an object because it uses `Self` as a type parameter
help: consider using an opaque type instead
   |
LL | fn ord_prefer_dot(s: String) -> impl Ord {
   |                                 ++++
```
2024-01-05 10:57:20 -05:00
Matthew Jasper
26f48b4cba Stabilize THIR unsafeck 2024-01-05 10:00:59 +00:00
Matthew Jasper
982b49494e Remove revisions for THIR unsafeck
This is to make the diff when stabilizing it easier to review.
2024-01-05 09:30:27 +00:00
bors
5113ed28ea Auto merge of #118297 - shepmaster:warn-dead-tuple-fields, r=WaffleLapkin
Merge `unused_tuple_struct_fields` into `dead_code`

This implicitly upgrades the lint from `allow` to `warn` and places it into the `unused` lint group.

[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Moving.20.60unused_tuple_struct_fields.60.20from.20allow.20to.20warn)
2024-01-05 04:51:55 +00:00
bors
791a53f380 Auto merge of #117213 - oli-obk:check_item_type_cleanup, r=estebank
Reorder check_item_type diagnostics so they occur next to the corresponding `check_well_formed` diagnostics

The first commit is just a cleanup.

The second commit moves most checks from `check_mod_item_types` into `check_well_formed`, invoking the checks in lockstep per-item instead of iterating over all items twice.
2024-01-05 00:04:08 +00:00
Esteban Küber
698dfc322f Silence redundant warning when E0038 will be emitted 2024-01-04 00:46:33 +00:00
Esteban Küber
79bef72fd5 Track HirId instead of Span in ObligationCauseCode::SizedArgumentType
This gets us more accurate suggestions.
2024-01-03 18:59:42 +00:00
Esteban Küber
8551cab7b7 Account for multiple trait bounds in bare trait object suggestion
Note the parentheses in the last suggestion:

```
error[E0277]: the size for values of type `(dyn Foo + Send + 'static)` cannot be known at compilation time
  --> $DIR/not-on-bare-trait.rs:7:8
   |
LL | fn foo(_x: Foo + Send) {
   |        ^^ doesn't have a size known at compile-time
   |
   = help: the trait `Sized` is not implemented for `(dyn Foo + Send + 'static)`
   = help: unsized fn params are gated as an unstable feature
help: you can use `impl Trait` as the argument type
   |
LL | fn foo(_x: impl Foo + Send) {
   |            ++++
help: function arguments must have a statically known size, borrowed types always have a known size
   |
LL | fn foo(_x: &(Foo + Send)) {
   |            ++          +
```
2024-01-03 18:59:42 +00:00
Esteban Küber
0487500776 Provide better suggestions when encountering a bare trait as a type
Add the following suggestions:

```
error[E0782]: trait objects must include the `dyn` keyword
  --> $DIR/not-on-bare-trait-2021.rs:11:11
   |
LL | fn bar(x: Foo) -> Foo {
   |           ^^^
   |
help: use a generic type parameter, constrained by the trait `Foo`
   |
LL | fn bar<T: Foo>(x: T) -> Foo {
   |       ++++++++    ~
help: you can also use `impl Foo`, but users won't be able to specify the type paramer when calling the `fn`, having to rely exclusively on type inference
   |
LL | fn bar(x: impl Foo) -> Foo {
   |           ++++
help: alternatively, use a trait object to accept any type that implements `Foo`, accessing its methods at runtime using dynamic dispatch
   |
LL | fn bar(x: &dyn Foo) -> Foo {
   |           ++++

error[E0782]: trait objects must include the `dyn` keyword
  --> $DIR/not-on-bare-trait-2021.rs:11:19
   |
LL | fn bar(x: Foo) -> Foo {
   |                   ^^^
   |
help: use `impl Foo` to return an opaque type, as long as you return a single underlying type
   |
LL | fn bar(x: Foo) -> impl Foo {
   |                   ++++
help: alternatively, you can return an owned trait object
   |
LL | fn bar(x: Foo) -> Box<dyn Foo> {
   |                   +++++++    +
```
2024-01-03 18:59:42 +00:00
Jake Goulding
53eca9fa87 Adjust compiler tests for unused_tuple_struct_fields -> dead_code 2024-01-02 15:34:37 -05:00
Oli Scherer
cd4c352fb4 Reorder check_item_type diagnostics so they occur next to the corresponding check_well_formed diagnostics 2024-01-02 14:17:56 +00:00
León Orell Valerian Liehr
3d0297a1e1
Deny defaults for higher-ranked generic parameters 2024-01-01 21:58:25 +01:00
León Orell Valerian Liehr
977546d3fc
rustc_middle: Pretty-print negative bounds correctly 2023-12-28 00:58:56 +01:00
León Orell Valerian Liehr
a251974015
Deny parenthetical notation for negative bounds 2023-12-28 00:50:16 +01:00
León Orell Valerian Liehr
5f56465621
Make feature negative_bounds internal 2023-12-28 00:43:35 +01:00
bohan
e16efbd23a fallback default to None during ast-loweing for lifetime binder 2023-12-26 16:10:29 +08:00
Matthias Krüger
2b48e7dbcb
Rollup merge of #119154 - surechen:fix_119067, r=fmease
Simple modification of `non_lifetime_binders`'s diagnostic information to adapt to type binders

fixes #119067

Replace diagnostic information "lifetime bounds cannot be used in this context" to "bounds cannot be used in this context".

```rust
#![allow(incomplete_features)]
#![feature(non_lifetime_binders)]

trait Trait {}

trait Trait2
    where for <T: Trait> ():{}
//~^ ERROR bounds cannot be used in this context
```
2023-12-21 16:43:07 +01:00
surechen
4897d5eccf Simple modification of diagnostic information
fixes #119067
2023-12-21 10:17:11 +08:00
Matthias Krüger
16a231d8eb
Rollup merge of #119071 - lcnr:overflowo, r=compiler-errors
-Znext-solver: adapt overflow rules to avoid breakage

Do not erase overflow constraints if they are from equating the impl header when normalizing[^1].

This should be the minimal change to not break crates depending on the old project behavior of "apply impl constraints while only lazily evaluating any nested goals".

Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/70, see https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg for the reasoning behind this.

Only keeping constraints on overflow for `normalize-to` goals as that's the only thing needed for backcompat. It also allows us to not track the origin of root obligations. The issue with root goals would be something like the following:

```rust
trait Foo {}
trait Bar {}

trait FooBar {}
impl<T: Foo + Bar> FooBar for T {}

// These two should behave the same, rn we can drop constraints for both,
// but if we don't drop `Misc` goals we would only drop the constraints for
// `FooBar` unless we track origins of root obligations.
fn func1<T: Foo + Bar>() {}
fn func2<T: FooBaz>() {}
```

[^1]: mostly, the actual rules are slightly different

r? ``@compiler-errors``
2023-12-20 09:46:11 +01:00
Michael Goulet
132a2884ad Use alias-eq in structural normalization 2023-12-18 19:22:43 +00:00
lcnr
4a38442c90 dont discard overflow from normalizes-to goals 2023-12-18 09:01:54 +01:00
bohan
64e311add2 skip rpit constraint check if borrowck return type error 2023-12-17 16:49:00 +08:00
Jubilee
1d54949765
Rollup merge of #118396 - compiler-errors:ast-lang-items, r=cjgillot
Collect lang items from AST, get rid of `GenericBound::LangItemTrait`

r? `@cjgillot`
cc #115178

Looking forward, the work to remove `QPath::LangItem` will also be significantly more difficult, but I plan on doing it as well. Specifically, we have to change:
1. A lot of `rustc_ast_lowering` for things like expr `..`
2. A lot of astconv, since we actually instantiate lang and non-lang paths quite differently.
3. A ton of diagnostics and clippy lints that are special-cased via `QPath::LangItem`

Meanwhile, it was pretty easy to remove `GenericBound::LangItemTrait`, so I just did that here.
2023-12-15 14:08:15 -08:00
Michael Goulet
5b0b7cd8f9 Move type relations into submodule in rustc_infer 2023-12-15 18:13:40 +00:00
Michael Goulet
ad00641b74 Collect lang items from AST 2023-12-15 16:12:27 +00:00
Michael Goulet
146e345d8b Opportunistically resolve region var in canonicalizer 2023-12-15 05:02:37 +00:00
Michael Goulet
929d632b54 Unconditionally register alias-relate in projection goal 2023-12-14 18:41:23 +00:00
lcnr
0947070871 consistently use "next solver" instead of "new solver" 2023-12-14 15:22:37 +01:00
lcnr
11d16c4082 update use of feature flags 2023-12-14 15:22:37 +01:00
Esteban Küber
9d846fcc11 Tweak short_ty_string to reduce number of files
When shortening types and writing them to disk, make `short_ty_string`
capable of reusing the same file, instead of writing a file per
shortened type.
2023-12-13 23:07:10 +00:00
lcnr
6ffe36b37d refactor writeback: emit normalization errors with new solver 2023-12-12 12:20:54 +00:00
bors
84f6130fe3 Auto merge of #118692 - surechen:remove_unused_imports, r=petrochenkov
remove redundant imports

detects redundant imports that can be eliminated.

for #117772 :

In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.

r? `@petrochenkov`
2023-12-10 11:55:48 +00:00
surechen
40ae34194c remove redundant imports
detects redundant imports that can be eliminated.

for #117772 :

In order to facilitate review and modification, split the checking code and
removing redundant imports code into two PR.
2023-12-10 10:56:22 +08:00
lcnr
ef796db5f0 add test for inductive cycle hangs 2023-12-09 10:35:07 +00:00
Matthias Krüger
943fa33daf
Rollup merge of #118730 - jyn514:cmp_refs, r=estebank,compiler-errors
recurse into refs when comparing tys for diagnostics

before:
![image](https://github.com/rust-lang/rust/assets/23638587/bf6abd62-c7f3-4c09-a47e-31b6e129de19)

after:
![image](https://github.com/rust-lang/rust/assets/23638587/b704d728-ddba-4204-aebe-c07dcbbcb55c)

this diff from the test suite is also quite nice imo:
```diff
`@@` -4,8 +4,8 `@@` error[E0308]: mismatched types
 LL |     debug_assert_eq!(iter.next(), Some(value));
    |                                   ^^^^^^^^^^^ expected `Option<<I as Iterator>::Item>`, found `Option<&<I as Iterator>::Item>`
    |
-   = note: expected enum `Option<<I as Iterator>::Item>`
-              found enum `Option<&<I as Iterator>::Item>`
+   = note: expected enum `Option<_>`
+              found enum `Option<&_>`
```
2023-12-08 23:15:13 +01:00
jyn
eb53721a34 recurse into refs when comparing tys for diagnostics 2023-12-07 23:00:46 -05:00
lcnr
1490c58076 add regression tests 2023-12-08 01:34:40 +01:00
lcnr
ffb4c08a81 implement and use NormalizesTo 2023-12-08 01:31:18 +01:00
Matthias Krüger
f1e180451b
Rollup merge of #116496 - estebank:question-method-chain-context, r=compiler-errors
Provide context when `?` can't be called because of `Result<_, E>`

When a method chain ending in `?` causes an E0277 because the expression's `Result::Err` variant doesn't have a type that can be converted to the `Result<_, E>` type parameter in the return type, provide additional context of which parts of the chain can and can't support the `?` operator.

```
error[E0277]: `?` couldn't convert the error to `String`
  --> $DIR/question-mark-result-err-mismatch.rs:27:25
   |
LL | fn bar() -> Result<(), String> {
   |             ------------------ expected `String` because of this
LL |     let x = foo();
   |             ----- this has type `Result<_, String>`
...
LL |         .map_err(|_| ())?;
   |          ---------------^ the trait `From<()>` is not implemented for `String`
   |          |
   |          this can't be annotated with `?` because it has type `Result<_, ()>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             <String as From<char>>
             <String as From<Box<str>>>
             <String as From<Cow<'a, str>>>
             <String as From<&str>>
             <String as From<&mut str>>
             <String as From<&String>>
   = note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>`
```

Fix #72124.
2023-12-06 17:21:56 +01:00
Esteban Küber
70fe624b3d Reduce verbosity of error 2023-12-05 22:24:33 +00:00
Esteban Küber
98e5317173 Detect incorrect ; in Option::ok_or_else and Result::map_err
Fix #72124.
2023-12-05 22:24:29 +00:00
Esteban Küber
53817963ed Point at fewer methods in the chain, only those that change the E type 2023-12-05 22:22:13 +00:00
Esteban Küber
6c3879d1f1 Provide context when ? can't be called because of Result<_, E>
When a method chain ending in `?` causes an E0277 because the
expression's `Result::Err` variant doesn't have a type that can be
converted to the `Result<_, E>` type parameter in the return type,
provide additional context of which parts of the chain can and can't
support the `?` operator.

```
error[E0277]: `?` couldn't convert the error to `String`
  --> $DIR/question-mark-result-err-mismatch.rs:28:25
   |
LL | fn bar() -> Result<(), String> {
   |             ------------------ expected `String` because of this
LL |     let x = foo();
   |             ----- this can be annotated with `?` because it has type `Result<String, String>`
LL |     let one = x
LL |         .map(|s| ())
   |          ----------- this can be annotated with `?` because it has type `Result<(), String>`
LL |         .map_err(|_| ())?;
   |          ---------------^ the trait `From<()>` is not implemented for `String`
   |          |
   |          this can't be annotated with `?` because it has type `Result<(), ()>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             <String as From<char>>
             <String as From<Box<str>>>
             <String as From<Cow<'a, str>>>
             <String as From<&str>>
             <String as From<&mut str>>
             <String as From<&String>>
   = note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>`
```

Fix #72124.
2023-12-05 22:22:08 +00:00
Michael Goulet
b97ff8eb16 Add print_trait_sugared 2023-12-05 17:15:46 +00:00
lcnr
cf8a2bdd81 rebase 2023-12-04 10:48:00 +01:00
lcnr
407c117e88 cleanup and comments 2023-12-04 10:40:36 +01:00
lcnr
f69d67221e generalize: handle occurs check failure in aliases 2023-12-04 10:39:00 +01:00
Matthew Jasper
942e93972d Handle recursion limit for subtype and well-formed predicates 2023-12-01 17:25:02 +00:00
Nilstrieb
41e8d152dc Show number in error message even for one error
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-11-24 19:15:52 +01:00