about summary refs log tree commit diff
path: root/tests/ui/associated-consts
AgeCommit message (Collapse)AuthorLines
2025-07-13Auto merge of #143357 - cjgillot:no-assoc-item-kind, r=compiler-errorsbors-3/+3
Retire hir::*ItemRef. This information was kept for various places that iterate on HIR to know about trait-items and impl-items. This PR replaces them by uses of the `associated_items` query that contain pretty much the same information. This shortens many spans to just `def_span`, which can be easier to read.
2025-07-13Retire hir::*ItemRef.Camille GILLOT-3/+3
2025-07-10Check assoc consts and tys later like assoc fnsMu001999-0/+44
2025-06-30Use predicate spans instead of whole item spansOli Scherer-4/+8
2025-06-26Move an ACE test out of the GCI directoryLeón Orell Valerian Liehr-0/+17
2025-06-02Clarify why we are talking about a failed const eval at a random placeOli Scherer-1/+1
2025-06-02Use the informative error as the main const eval error messageOli Scherer-3/+3
2025-05-21lower bodies' params to thir before the body's valuedianne-9/+9
2025-04-30compiletest: Make diagnostic kind mandatory on line annotationsVadim Petrochenkov-6/+7
2025-04-08UI tests: add missing diagnostic kinds where possibleVadim Petrochenkov-1/+1
2025-04-04Apply `Recovery::Forbidden` when reparsing pasted macro fragments.Nicholas Nethercote-25/+10
Fixes #137874. Removes `tests/crashes/137874.rs`; the new test is simpler (defines its own macro) but tests the same thing. The changes to the output of `tests/ui/associated-consts/issue-93835.rs` partly undo the changes seen when `NtTy` was removed in #133436, which is good.
2025-02-22Auto merge of #133436 - nnethercote:rm-NtVis-NtTy, r=petrochenkovbors-7/+34
Remove `NtVis` and `NtTy` The next part of #124141. The first actual remove of `Nonterminal` variants. `NtVis` is a simple case that doesn't get much use, but `NtTy` is more complex. r? `@petrochenkov`
2025-02-22Auto merge of #137406 - matthiaskrgr:rollup-9nknrsb, r=matthiaskrgrbors-4/+63
Rollup of 8 pull requests Successful merges: - #136458 (Do not deduplicate list of associated types provided by dyn principal) - #136474 ([`compiletest`-related cleanups 3/7] Make the distinction between sources root vs test suite sources root in compiletest less confusing) - #136592 (Make sure we don't overrun the stack in canonicalizer) - #136787 (Remove `lifetime_capture_rules_2024` feature) - #137207 (Add #[track_caller] to Duration Div impl) - #137245 (Tweak E0277 when predicate comes indirectly from ?) - #137257 (Ignore fake borrows for packed field check) - #137399 (fix ICE in layout computation with unnormalizable const) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-21Make sure we don't overrun the stack in canonicalizerMichael Goulet-4/+63
2025-02-21Remove `NtTy`.Nicholas Nethercote-7/+34
Notes about tests: - tests/ui/parser/macro/trait-object-macro-matcher.rs: the syntax error is duplicated, because it occurs now when parsing the decl macro input, and also when parsing the expanded decl macro. But this won't show up for normal users due to error de-duplication. - tests/ui/associated-consts/issue-93835.rs: similar, plus there are some additional errors about this very broken code. - The changes to metavariable descriptions in #132629 are now visible in error message for several tests.
2025-02-21More sophisticated span trimmingMichael Goulet-6/+4
2025-02-14fallout :skull_emoji:lcnr-13/+30
2025-02-10Show diff suggestion format on verbose replacementEsteban Küber-4/+6
``` error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields --> $DIR/attempted-access-non-fatal.rs:7:15 | LL | let _ = 2.l; | ^ | help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix | LL - let _ = 2.l; LL + let _ = 2.0f64; | ```
2025-02-03Check Sizedness of return type in WFMichael Goulet-9/+9
2025-01-26Compiler: Finalize dyn compatibility renamingLeón Orell Valerian Liehr-2/+2
2025-01-22Refactor dyn-compatibility error and suggestionsTaylor Cramer-10/+12
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
2024-12-22Add `ignore-rustc-debug-assertions` to ↵DianQK-3/+3
`tests/ui/associated-consts/issue-93775.rs`
2024-12-16Disable `tests\ui\associated-consts\issue-93775.rs` on windows msvc许杰友 Jieyou Xu (Joe)-0/+4
This test seems to be quite flaky. See: - https://github.com/rust-lang/rust/issues/132111 - https://github.com/rust-lang/rust/issues/133432
2024-12-06Hide errors whose suggestions would contain error constants or typesOli Scherer-6/+0
2024-12-06Silence follow-up errors from `lit_to_const`Oli Scherer-2/+2
2024-12-04review comments: reword messages and simplify logicEsteban Küber-12/+12
2024-12-04Point at generic param through which a const is used in a patternEsteban Küber-8/+19
``` error[E0158]: constant pattern depends on a generic parameter, which is not allowed --> $DIR/associated-const-type-parameter-pattern.rs:20:9 | LL | pub trait Foo { | ------------- LL | const X: EFoo; | ------------- constant defined here ... LL | pub fn test<A: Foo, B: Foo>(arg: EFoo) { | - constant depends on this generic param LL | match arg { LL | A::X => println!("A::X"), | ^^^^ `const` depends on a generic parameter ```
2024-12-04On `const` pattern errors, point at the `const` item definitionEsteban Küber-0/+20
Centralize emitting an error in `const_to_pat` so that all errors from that evaluating a `const` in a pattern can add addditional information. With this, now point at the `const` item's definition: ``` error[E0158]: constant pattern depends on a generic parameter --> $DIR/associated-const-type-parameter-pattern.rs:20:9 | LL | pub trait Foo { | ------------- LL | const X: EFoo; | ------------- constant defined here ... LL | A::X => println!("A::X"), | ^^^^ ```
2024-11-27Bless tests due to extra error reporting due to normalizing types that are ↵Michael Goulet-1/+10
not WF It's okay though b/c these are duplicated diagnostics.
2024-10-29Remove detail from label/note that is already available in other noteEsteban Küber-1/+1
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-09-25Compiler: Rename "object safe" to "dyn compatible"León Orell Valerian Liehr-2/+2
2024-09-16Relate receiver invariantly in method probe for Mode::PathMichael Goulet-4/+32
2024-07-18avoid creating an Instance only to immediately disassemble it againRalf Jung-17/+35
2024-07-17Fix associated item removal suggestionEsteban Küber-4/+6
We were previously telling people to write what was already there, instead of removal. ``` error[E0229]: associated item constraints are not allowed here --> $DIR/E0229.rs:13:25 | LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {} | ^^^^^^^ associated item constraint not allowed here | help: consider removing this associated item binding | LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {} LL + fn baz<I>(x: &<I as Foo>::A) {} | ```
2024-06-17Use subtyping instead of equality, since method resolution also uses subtypingOli Scherer-0/+59
2024-06-14Resolve elided lifetimes in assoc const to static if no other lifetimes are ↵Michael Goulet-69/+4
in scope
2024-05-30Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanupLeón Orell Valerian Liehr-8/+8
2024-05-13Apply nitsMichael Goulet-36/+6
2024-04-16Emit suggestions when equality constraints are wrongly usedGurinder Singh-0/+9
2024-03-27Sort method suggestions by `DefPath` instead of `DefId`Oli Scherer-6/+6
2024-03-20Bless test fallout (duplicate diagnostics)Michael Goulet-6/+61
2024-03-19Auto merge of #122055 - compiler-errors:stabilize-atb, r=oli-obkbors-12/+1
Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See #112573/#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: https://github.com/rust-lang/rust/pull/120752#issuecomment-1979412531. * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See #120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * #57428 * #108063 * #110512 * #112629 * #120719 * #120584 Closes #52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html
2024-03-13Reject escaping bound vars in the type of assoc const bindingsLeón Orell Valerian Liehr-0/+99
2024-03-13Reject early-bound params in the type of assoc const bindingsLeón Orell Valerian Liehr-0/+131
2024-03-11Rollup merge of #119385 - fmease:assoc-const-eq-fixes-2, r=oli-obk,cjgillotJubilee-6/+26
Fix type resolution of associated const equality bounds (take 2) Instead of trying to re-resolve the type of assoc const bindings inside the `type_of` query impl in an incomplete manner, transfer the already (correctly) resolved type from `add_predicates_for_ast_type_binding` to `type_of`/`anon_type_of` through query feeding. --- Together with #118668 (merged) and #121258, this supersedes #118360. Fixes #118040. r? ``@ghost``
2024-03-11Rollup merge of #121840 - oli-obk:freeze, r=dtolnayJacob Pratt-0/+12
Expose the Freeze trait again (unstably) and forbid implementing it manually non-emoji version of https://github.com/rust-lang/rust/pull/121501 cc #60715 This trait is useful for generic constants (associated consts of generic traits). See the test (`tests/ui/associated-consts/freeze.rs`) added in this PR for a usage example. The builtin `Freeze` trait is the only way to do it, users cannot work around this issue. It's also a useful trait for building some very specific abstrations, as shown by the usage by the `zerocopy` crate: https://github.com/google/zerocopy/issues/941 cc ```@RalfJung``` T-lang signed off on reexposing this unstably: https://github.com/rust-lang/rust/pull/121501#issuecomment-1969827742
2024-03-08Stabilize associated type boundsMichael Goulet-12/+1
2024-03-01Never say "`Trait` is implemented for `{type error}`"Esteban Küber-2/+0
When a trait bound error occurs, we look for alternative types that would have made the bound succeed. For some reason `{type error}` sometimes would appear as a type that would do so. We now remove `{type error}` from the list in every case to avoid nonsensical `note`s.
2024-02-29Expose `Freeze` trait againOli Scherer-0/+12
2024-02-19Always evaluate free constants and statics, even if previous errors occurredOli Scherer-25/+29