Commit Graph

696 Commits

Author SHA1 Message Date
Michael Goulet
789ee88bd0 Tighten spans for async blocks 2024-06-27 15:19:08 -04:00
Matthias Krüger
dc9a08f535
Rollup merge of #126552 - fee1-dead-contrib:rmfx, r=compiler-errors
Remove use of const traits (and `feature(effects)`) from stdlib

The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.

Also, make `effects` an incomplete feature.

cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
2024-06-22 19:33:56 +02:00
Deadbeef
81da6a6d40 Make effects an incomplete feature 2024-06-22 14:11:11 +00:00
Esteban Küber
5d5892e966 Remove stray . from error message 2024-06-21 21:13:10 +00:00
bors
5978f35330 Auto merge of #126671 - fmease:rollup-dmet4fi, r=fmease
Rollup of 7 pull requests

Successful merges:

 - #123782 (Test that opaque types can't have themselves as a hidden type with incompatible lifetimes)
 - #124580 (Suggest removing unused tuple fields if they are the last fields)
 - #125787 (Migrate `bin-emit-no-symbols` `run-make` test to `rmake`)
 - #126553 (match lowering: expand or-candidates mixed with candidates above)
 - #126594 (Make async drop code more consistent with regular drop code)
 - #126654 (Make pretty printing for `f16` and `f128` consistent)
 - #126656 (rustc_type_ir: Omit some struct fields from Debug output)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-19 08:56:43 +00:00
bors
3c0f019b3c Auto merge of #125852 - bvanjoi:improve-tip-for-invisible-trait, r=compiler-errors
improve tip for inaccessible traits

Improve the tips when the candidate method is from an inaccessible trait.

For example:

```rs
mod m {
  trait Trait {
    fn f() {}
  }
  impl<T> Trait for T {}
}

fn main() {
  struct S;
  S::f();
}
```

The difference between before and now is:

```diff
error[E0599]: no function or associated item named `f` found for struct `S` in the current scope
  --> ./src/main.rs:88:6
   |
LL |   struct S;
   |   -------- function or associated item `f` not found for this struct
LL |   S::f();
   |      ^ function or associated item not found in `S`
   |
   = help: items from traits can only be used if the trait is implemented and in scope
- help: trait `Trait` which provides `f` is implemented but not in scope; perhaps you want to import it
+ help: trait `crate:Ⓜ️:Trait` which provides `f` is implemented but not reachable
   |
- LL + use crate:Ⓜ️:Trait;
   |
```
2024-06-19 06:19:22 +00:00
León Orell Valerian Liehr
2126c1d446
rustc_type_ir: Omit some struct fields from Debug output 2024-06-19 03:08:34 +02:00
Jacob Pratt
936d76009b
Rollup merge of #126127 - Alexendoo:other-trait-diag, r=pnkfelix
Spell out other trait diagnostic

I recently saw somebody confused about the diagnostic thinking it was suggesting to add an `as` cast. This change is longer but I think it's clearer
2024-06-16 03:41:57 -04:00
Michael Goulet
93ee07c756 Check that alias-relate terms are WF if reporting an error in alias-relate 2024-06-13 08:52:35 -04:00
Jubilee
25c55c51cb
Rollup merge of #126142 - compiler-errors:trait-ref-split, r=jackh726
Harmonize using root or leaf obligation in trait error reporting

When #121826 changed the error reporting to use root obligation and not the leafmost obligation, it didn't actually make sure that all the other diagnostics helper functions used the right obligation.

Specifically, when reporting similar impl candidates we are looking for impls of the root obligation, but trying to match them against the trait ref of the leaf obligation.

This does a few other miscellaneous changes. There's a lot more clean-up that could be done here, but working with this code is really grief-inducing due to how messy it has become over the years. Someone really needs to show it love. 😓

r? ``@estebank``

Fixes #126129
2024-06-12 20:03:19 -07:00
Michael Goulet
c453c82de4 Harmonize use of leaf and root obligation in trait error reporting 2024-06-12 20:57:23 -04:00
Michael Goulet
44040a0670 Also passthrough for projection clauses 2024-06-12 19:10:02 -04:00
Michael Goulet
b0c1474381 better error message for normalizes-to ambiguities 2024-06-12 19:03:37 -04:00
Michael Goulet
52b2c88bdf Walk into alias-eq nested goals even if normalization fails 2024-06-12 19:03:37 -04:00
Guillaume Gomez
99d0feedb8
Rollup merge of #126075 - compiler-errors:remove-debugwithinfcx, r=lcnr
Remove `DebugWithInfcx` machinery

This PR removes `DebugWithInfcx` after having a lot of second thoughts about it due to recent type system uplifting work. We could add it back later if we want, but I don't think the amount of boilerplate in the complier and the existence of (kindof) hacks like `NoInfcx` currently justify the existence of `DebugWithInfcx`, especially since it's not even being used anywhere in the compiler currently.

The motivation for `DebugWithInfcx` is that we want to be able to print infcx-aware information, such as universe information[^1] (though if there are other usages that I'm overlooking, please let me know). I think there are probably more tailored solutions that can specifically be employed in places where this infcx-aware printing is necessary. For example, one way of achieving this is by implementing a custom `FmtPrinter` which overloads `ty_infer_name` (perhaps also extending it to have overrideable stubs for printing placeholders too) to print the `?u.i` name for an infer var. This will necessitate uplifting `Print` from `rustc_middle::ty::print`, but this seems a bit more extensible and reusable than `DebugWithInfcx`.

One of the problems w/ `DebugWithInfcx` is its opt-in-ness. Even if a compiler dev adds a new `debug!(ty)` in a context where there is an `infcx` we can access, they have to *opt-in* to using `DebugWithInfcx` with something like `debug!(infcx.with(ty))`. This feels to me like it risks a lot of boilerplate, and very easy to just forget adding it at all, especially in cases like `#[instrument]`.

A second problem is the `NoInfcx` type itself. It's necessary to have this dummy infcx implementation since we often want to print types outside of the scope of a valid `Infcx`. Right now, `NoInfcx` is only *partially* a valid implementation of `InferCtxtLike`, except for the methods that we specifically need for `DebugWithInfcx`. As I work on uplifting the trait solver, I actually want to add a lot more methods to `InferCtxtLike` and having to add `unreachable!("this should never be called")` stubs for uplifted methods like `next_ty_var` is quite annoying.

In reality, I actually only *really* care about the second problem -- we could, perhaps, instead just try to get rid of `NoInfcx` and just just duplicate `Debug` and `DebugWithInfcx` for most types. If we're okay with duplicating all these implementations (though most of them would just be trivial `#[derive(Debug, DebugWithInfcx)]`), I'd be okay with that too 🤔

r? `@BoxyUwU` `@lcnr` would like to know your thoughts -- happy to discuss this further, mainly trying to bring this problem up

[^1]: Which in my experience is only really necessary when we're debugging things like generalizer bugs.
2024-06-12 15:44:58 +02:00
Alex Macleod
d0112c6849 Spell out other trait diagnostic 2024-06-12 12:34:47 +00:00
Jubilee
e7b07ea7a1
Rollup merge of #125978 - fmease:cleanup-hir-ty-lowering-consolidate-assoc-item-access-checking, r=davidtwco
Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking

Use `probe_assoc_item` (for hygienically probing an assoc item and checking if it's accessible wrt. visibility and stability) for assoc item constraints, too, not just for assoc type paths and make the privacy error translatable.
2024-06-12 03:57:19 -07:00
Michael Goulet
0fc18e3a17 Remove DebugWithInfcx 2024-06-11 22:13:04 -04:00
Matthias Krüger
13314df21b
Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix
Detect pub structs never constructed and unused associated constants

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Lints never constructed public structs.

If we don't provide public methods to construct public structs with private fields, and don't construct them in the local crate. They would be never constructed. So that we can detect such public structs.

---
Update:

Also lints unused associated constants in traits.
2024-06-07 20:14:28 +02:00
Matthias Krüger
dd2e1a3b34
Rollup merge of #126022 - lcnr:generalize-alias-bivariant, r=compiler-errors
set `has_unconstrained_ty_var` when generalizing aliases in bivariant contexts

this previously prevented the `regression-31157` benchmark from building

r? `@compiler-errors`
2024-06-05 18:21:12 +02:00
r0cky
35130d7233 Detect pub structs never constructed and unused associated constants in traits 2024-06-05 23:20:09 +08:00
lcnr
a8e091de4a bivariant alias: set has_unconstrained_ty_var 2024-06-05 11:48:03 +02:00
Jubilee
78d9a7e107
Rollup merge of #125906 - compiler-errors:simplify-method-error-args, r=fmease
Remove a bunch of redundant args from `report_method_error`

Rebased on top of #125397 because I had originally asked there (https://github.com/rust-lang/rust/pull/125397#discussion_r1610124799) for this change to be made, but I just chose to do it myself.

r? fmease
2024-06-05 01:14:32 -07:00
León Orell Valerian Liehr
c59a2b2746
Cleanup: HIR ty lowering: Consolidate assoc item access checking 2024-06-04 23:13:16 +02:00
许杰友 Jieyou Xu (Joe)
0dc65501cb
Rollup merge of #125608 - oli-obk:subsequent_lifetime_errors, r=BoxyUwU
Avoid follow-up errors if the number of generic parameters already doesn't match

fixes #125604

best reviewed commit-by-commit
2024-06-04 08:25:47 +01:00
Michael Goulet
8f08625443 Remove a bunch of redundant args from report_method_error 2024-06-03 20:29:09 -04:00
Michael Goulet
de6b219803 Make WHERE_CLAUSES_OBJECT_SAFETY a regular object safety violation 2024-06-03 09:49:04 -04:00
Oli Scherer
adb2ac0165 Mark all extraneous generic args as errors 2024-06-03 13:21:17 +00:00
Oli Scherer
61c4b7f1a7 Hide some follow-up errors 2024-06-03 13:03:53 +00:00
bors
1d52972dd8 Auto merge of #125778 - estebank:issue-67100, r=compiler-errors
Use parenthetical notation for `Fn` traits

Always use the `Fn(T) -> R` format when printing closure traits instead of `Fn<(T,), Output = R>`.

Address #67100:

```
error[E0277]: expected a `Fn()` closure, found `F`
 --> file.rs:6:13
  |
6 |     call_fn(f)
  |     ------- ^ expected an `Fn()` closure, found `F`
  |     |
  |     required by a bound introduced by this call
  |
  = note: wrap the `F` in a closure with no arguments: `|| { /* code */ }`
note: required by a bound in `call_fn`
 --> file.rs:1:15
  |
1 | fn call_fn<F: Fn() -> ()>(f: &F) {
  |               ^^^^^^^^^^ required by this bound in `call_fn`
help: consider further restricting this bound
  |
5 | fn call_any<F: std::any::Any + Fn()>(f: &F) {
  |                              ++++++
```
2024-06-03 08:14:03 +00:00
bohan
586821eacd tip for inaccessible traits 2024-06-03 15:03:06 +08:00
Matthias Krüger
ab55d42b74
Rollup merge of #125786 - compiler-errors:fold-item-bounds, r=lcnr
Fold item bounds before proving them in `check_type_bounds` in new solver

Vaguely confident that this is sufficient to prevent rust-lang/trait-system-refactor-initiative#46 and rust-lang/trait-system-refactor-initiative#62.

This is not the "correct" solution, but will probably suffice until coinduction, at which point we implement the right solution (`check_type_bounds` must prove `Assoc<...> alias-eq ConcreteType`, normalizing requires proving item bounds).

r? lcnr
2024-05-31 08:50:23 +02:00
Matthias Krüger
379233242b
Rollup merge of #125635 - fmease:mv-type-binding-assoc-item-constraint, r=compiler-errors
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup

Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.

Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.

---

Old terminology (HIR, rustdoc):

```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
    ├── `Ty`: (associated) type binding
    └── `Const`: associated const equality (constraint)
```

Old terminology (AST, abbrev.):

```
`AssocConstraint`
├── `Bound`
└── `Equality`
    ├── `Ty`
    └── `Const`
```

New terminology (AST, HIR, rustdoc):

```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
    ├── `Ty`: associated type equality constraint OR associated type binding (for short)
    └── `Const`: associated const equality constraint OR associated const binding (for short)
```

r? compiler-errors
2024-05-31 08:50:22 +02:00
León Orell Valerian Liehr
34c56c45cf
Rename HIR TypeBinding to AssocItemConstraint and related cleanup 2024-05-30 22:52:33 +02:00
Michael Goulet
2f4b7dc047 Fold item bound before checking that they hold 2024-05-30 15:52:29 -04:00
lcnr
f7d14b741e update UI tests 2024-05-30 15:26:48 +02:00
Esteban Küber
e6bd6c2044 Use parenthetical notation for Fn traits
Always use the `Fn(T) -> R` format when printing closure traits instead of `Fn<(T,), Output = R>`.

Fix #67100:

```
error[E0277]: expected a `Fn()` closure, found `F`
 --> file.rs:6:13
  |
6 |     call_fn(f)
  |     ------- ^ expected an `Fn()` closure, found `F`
  |     |
  |     required by a bound introduced by this call
  |
  = note: wrap the `F` in a closure with no arguments: `|| { /* code */ }`
note: required by a bound in `call_fn`
 --> file.rs:1:15
  |
1 | fn call_fn<F: Fn() -> ()>(f: &F) {
  |               ^^^^^^^^^^ required by this bound in `call_fn`
help: consider further restricting this bound
  |
5 | fn call_any<F: std::any::Any + Fn()>(f: &F) {
  |                              ++++++
```
2024-05-29 22:26:54 +00:00
lcnr
98bfd54b0a eagerly normalize when adding goals 2024-05-28 04:54:05 +00:00
lcnr
4d5a9bcb86 change selection test to run-pass 2024-05-28 04:44:45 +00:00
bors
b0f8618938 Auto merge of #125413 - lcnr:ambig-drop-region-constraints, r=compiler-errors
drop region constraints for ambiguous goals

See the comment in `compute_external_query_constraints`. While the underlying issue is preexisting, this fixes a bug introduced by #125343.

It slightly weakens the leak chec, even if we didn't have any test which was affected. I want to write such a test before merging this PR.

r? `@compiler-errors`
2024-05-27 15:28:51 +00:00
Matthias Krüger
1e841638e3
Rollup merge of #124080 - oli-obk:define_opaque_types10, r=compiler-errors
Some unstable changes to where opaque types get defined

None of these can be reached from stable afaict.

r? ``@compiler-errors``

cc https://github.com/rust-lang/rust/issues/116652
2024-05-25 22:15:17 +02:00
lcnr
24b5466892 drop region constraints for ambiguous goals 2024-05-24 20:32:35 +00:00
Michael Goulet
61aac551b8 Structurally resolve before builtin_index in EUV 2024-05-24 16:20:48 -04:00
Oli Scherer
4387eea7f7 Support constraining opaque types while trait upcasting with binders 2024-05-23 16:02:24 +00:00
Oli Scherer
7f292f41a0 Allow defining opaque types during trait object upcasting.
No stable code is affected, as this requires the `trait_upcasting` feature gate.
2024-05-23 16:02:20 +00:00
Oli Scherer
dc8d1bc373 Add more tests 2024-05-23 15:48:06 +00:00
bors
e8fbd99128 Auto merge of #124097 - compiler-errors:box-into-iter, r=WaffleLapkin
Add `IntoIterator` for `Box<[T]>` + edition 2024-specific lints

* Adds a similar method probe opt-out mechanism to the `[T;N]: IntoIterator` implementation for edition 2021.
* Adjusts the relevant lints (shadowed `.into_iter()` calls, new source of method ambiguity).
* Adds some tests.
* Took the liberty to rework the logic in the `ARRAY_INTO_ITER` lint, since it was kind of confusing.

Based mostly off of #116607.

ACP: rust-lang/libs-team#263
References #59878
Tracking for Rust 2024: https://github.com/rust-lang/rust/issues/123759

Crater run was done here: https://github.com/rust-lang/rust/pull/116607#issuecomment-1770293013
Consensus afaict was that there is too much breakage, so let's do this in an edition-dependent way much like `[T; N]: IntoIterator`.
2024-05-21 10:13:53 +00:00
Michael Goulet
a502e7ac1d Implement BOXED_SLICE_INTO_ITER 2024-05-20 19:21:30 -04:00
lcnr
f99c9ffd88 track cycle participants per entry 2024-05-20 20:57:14 +00:00
bors
eb1a5c9bb3 Auto merge of #125077 - spastorino:add-new-fnsafety-enum2, r=jackh726
Rename Unsafe to Safety

Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.

This leaves us today with:

```rust
enum ast::Safety {
    Unsafe(Span),
    Default,
    // Safe (going to be added for unsafe extern blocks)
}

enum hir::Safety {
    Unsafe,
    Safe,
}
```

We would convert from `ast::Safety::Default` into the right Safety level according the context.
2024-05-18 19:35:24 +00:00