about summary refs log tree commit diff
path: root/tests/ui/associated-consts
AgeCommit message (Collapse)AuthorLines
2025-09-13Rollup merge of #145896 - Oneirical:uncountable-integer-10, r=jieyouxuJacob Pratt-0/+39
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2] Part of rust-lang/rust#133895 Methodology: 1. Refer to the previously written `tests/ui/SUMMARY.md` 2. Find an appropriate category for the test, using the original issue thread and the test contents. 3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers) 4. Rename the tests to make their purpose clearer Inspired by the methodology that `@Kivooeo` was using. r? `@jieyouxu`
2025-09-12Add test batch 3Oneirical-0/+39
2025-08-22On E0277, point at type that doesn't implement boundEsteban Küber-2/+12
When encountering an unmet trait bound, point at local type that doesn't implement the trait: ``` error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied --> $DIR/issue-64855.rs:9:19 | LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ; | ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound | help: the trait `Foo` is not implemented for `Bar<T>` --> $DIR/issue-64855.rs:9:1 | LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ; | ^^^^^^^^^^^^^^^^^ ```
2025-08-19bless tests with new lint messagesKarol Zwolak-1/+1
2025-08-17Rehome tests/ui/issues/ tests [5/?]Oneirical-0/+23
2025-08-06Rollup merge of #144552 - Oneirical:uncountable-integer-3, r=jieyouxuJakub Beránek-0/+17
Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` rust-lang/rust#143902 divided into smaller, easier to review chunks. Part of rust-lang/rust#133895 Methodology: 1. Refer to the previously written `tests/ui/SUMMARY.md` 2. Find an appropriate category for the test, using the original issue thread and the test contents. 3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers) 4. Rename the tests to make their purpose clearer Inspired by the methodology that ``@Kivooeo`` was using. r? ``@jieyouxu``
2025-08-04Rehome tests/ui/issues/ tests [3/?]Oneirical-0/+17
2025-08-02Rehome tests/ui/issues/ tests [2/?]Oneirical-0/+23
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