about summary refs log tree commit diff
path: root/src/test/ui/wf
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-2109/+0
2023-01-08Normalize assumed_wf_types after wfchecking is complete, for better spansMichael Goulet-2/+2
2023-01-08Improve spans of non-WF implied bound typesMichael Goulet-4/+4
2022-12-13Make some diagnostics not depend on the source of what they reference being ↵Oli Scherer-9/+0
available
2022-12-05Don't call diagnostic_hir_wf_check query if we have infer variablesMichael Goulet-0/+50
2022-10-26Process registered region obligation in resolve_regions_with_wf_tysMichael Goulet-0/+36
2022-08-30Tweak WellFormedLocs a bitMichael Goulet-2/+2
2022-08-22Auto merge of #100676 - lcnr:implied-bounds-yay, r=nikomatsakisbors-2/+2
implied bounds: explicitly state which types are assumed to be wf Adds a new query which maps each definition to the types which that definition assumes to be well formed. The intent is to make it easier to reason about implied bounds. This change should not influence the user-facing behavior of rustc. Notably, `borrowck` still only assumes that the function signature of associated functions is well formed while `wfcheck` assumes that the both the function signature and the impl trait ref is well formed. Not sure if that by itself can trigger UB or whether it's just annoying. As a next step, we can add `WellFormed` predicates to `predicates_of` of these items and can stop adding the wf bounds at each place which uses them. I also intend to move the computation from `assumed_wf_types` to `implied_bounds` into the `param_env` computation. This requires me to take a deeper look at `compare_predicate_entailment` which is currently somewhat weird wrt implied bounds so I am not touching this here. r? `@nikomatsakis`
2022-08-18Reword "Required because of the requirements on the impl of ..."Andy Wang-12/+12
2022-08-17implied_bounds: clarify our assumptionslcnr-2/+2
2022-07-15Remove some more usages of guess_head_spanMichael Goulet-2/+6
2022-07-13Always use CreateParameter mode for function definitions.Camille GILLOT-3/+3
2022-07-01Shorten def_span for more items.Camille GILLOT-2/+2
2022-06-27Rollup merge of #97780 - compiler-errors:field-wfcheck-before-sized, r=jackh726Matthias Krüger-0/+31
Check ADT field is well-formed before checking it is sized Fixes #96810. There is one diagnostics regression, in [`src/test/ui/generic-associated-types/bugs/issue-80626.stderr`](https://github.com/rust-lang/rust/pull/97780/files#diff-53795946378e78a0af23a10277c628ff79091c18090fdc385801ee70c1ba6963). I am not super concerned about it, since it's GAT related. We _could_ fix it, possibly by using the `FieldSized` obligation cause code instead of `BuiltinDerivedObligation`. But that would require changing `Sized` trait confirmation and the `adt_sized_constraint` query.
2022-06-19Include ForeignItem when visiting types for WF checkPreston From-0/+33
Addresses Issue 95665 by including `hir::Node::ForeignItem` as a valid type to visit in `diagnostic_hir_wf_check`. Fixes #95665
2022-06-05Do wfcheck on ADT field before Sized checkMichael Goulet-0/+31
2022-06-03Fully stabilize NLLJack Huey-158/+12
2022-05-06Resolve vars in note_type_errJack Huey-2/+2
2022-04-30Bless tests.Camille GILLOT-15/+30
2022-04-17Lint elided lifetimes in path on the AST.Camille GILLOT-1/+5
2022-04-05Rollup merge of #95591 - jackh726:nll-revisions-1, r=oli-obkDylan DPC-36/+50
Use revisions to track NLL test output (part 1) The idea here is 2 fold: 1) When we eventually do make NLL default on, that PR should be systematic in "delete revisions and corresponding error annotations" 2) This allows us to look at test NLL outputs in chunks. (Though, I've opted here not to "mark" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.) The actual review here should be "easy", but a bit tedious. I expect we should manually go through each test output and confirm it's okay. The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call, rather than just the function name in that call) 2) "E0308 mismatched types" -> "lifetime does not live long enough" 3) "E0495 cannot infer an appropriate lifetime for lifetime parameter" -> "lifetime does not live long enough" 4) "E0312 lifetime of reference outlives lifetime of borrowed content" -> "lifetime does not live long enough" 5) "E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement" -> "lifetime does not live long enough" 6) "E0623 lifetime mismatch" -> "lifetime does not live long enough" Other than the now lack of an error code, most of these look fine (with most giving more helpful suggestions now). `rfc1623` output isn't great. cc ``@marmeladema`` if you want to look through these Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)
2022-04-05More nll revisionsJack Huey-36/+50
2022-04-05Rollup merge of #95525 - ohno418:suggest-derivable-trait-E0277, ↵Dylan DPC-0/+8
r=compiler-errors Suggest derivable trait on E0277 error Closes https://github.com/rust-lang/rust/issues/95099 .
2022-04-05Suggest derivable trait on E0277ohno418-0/+8
2022-04-04Mention implementers of unsatisfied traitEsteban Kuber-0/+2
When encountering an unsatisfied trait bound, if there are no other suggestions, mention all the types that *do* implement that trait: ``` error[E0277]: the trait bound `f32: Foo` is not satisfied --> $DIR/impl_wf.rs:22:6 | LL | impl Baz<f32> for f32 { } | ^^^^^^^^ the trait `Foo` is not implemented for `f32` | = help: the following other types implement trait `Foo`: Option<T> i32 str note: required by a bound in `Baz` --> $DIR/impl_wf.rs:18:31 | LL | trait Baz<U: ?Sized> where U: Foo { } | ^^^ required by this bound in `Baz` ``` Mention implementers of traits in `ImplObligation`s. Do not mention other `impl`s for closures, ranges and `?`.
2022-03-24Properly track `ImplObligation`sEsteban Kuber-10/+2
Instead of probing for all possible impls that could have caused an `ImplObligation`, keep track of its `DefId` and obligation spans for accurate error reporting. Follow up to #89580. Addresses #89418. Remove some unnecessary clones. Tweak output for auto trait impl obligations.
2022-02-28Update ui test with the add of E0726 explanationGuillaume Gomez-0/+1
2021-12-31Ensure that early-bound function lifetimes are always 'local'Aaron Hill-5/+5
During borrowchecking, we treat any free (early-bound) regions on the 'defining type' as `RegionClassification::External`. According to the doc comments, we should only have 'external' regions when checking a closure/generator. However, a plain function can also have some if its regions be considered 'early bound' - this occurs when the region is constrained by an argument, appears in a `where` clause, or in an opaque type. This was causing us to incorrectly mark these regions as 'external', which caused some diagnostic code to act as if we were referring to a 'parent' region from inside a closure. This PR marks all instantiated region variables as 'local' when we're borrow-checking something other than a closure/generator/inline-const.
2021-12-14extend `simplify_type`lcnr-2/+10
2021-11-20Point at source of trait bound obligations in more placesEsteban Kuber-6/+0
Be more thorough in using `ItemObligation` and `BindingObligation` when evaluating obligations so that we can point at trait bounds that introduced unfulfilled obligations. We no longer incorrectly point at unrelated trait bounds (`substs-ppaux.verbose.stderr`). In particular, we now point at trait bounds on method calls. We no longer point at "obvious" obligation sources (we no longer have a note pointing at `Trait` saying "required by a bound in `Trait`", like in `associated-types-no-suitable-supertrait*`). Address part of #89418.
2021-10-13Remove textual span from diagnostic stringOli Scherer-13/+13
2021-09-23Support incremental in compiletest for non-incremental modes.Eric Huss-1/+1
2021-09-15Move object safety suggestions to the end of the errorEsteban Kuber-2/+2
2021-08-16Use note to point at bound introducing requirementEsteban Küber-107/+172
2021-08-12Use a more accurate span on assoc types WF checksEsteban Kuber-10/+10
2021-08-11Modify structured suggestion outputEsteban Küber-25/+25
* On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-08-09Do not ICE on HIR based WF check when involving lifetimesEsteban Küber-0/+45
Fix #87549.
2021-08-04Remove trailing whitespace from error messagesFabian Wolff-1/+1
2021-07-28Fix ICE in `diagnostic_hir_wf_check`Fabian Wolff-0/+26
2021-07-22Extend HIR WF checking to fieldsAaron Hill-6/+6
2021-07-20Support HIR wf checking for function signaturesAaron Hill-8/+11
During function type-checking, we normalize any associated types in the function signature (argument types + return type), and then create WF obligations for each of the normalized types. The HIR wf code does not currently support this case, so any errors that we get have imprecise spans. This commit extends `ObligationCauseCode::WellFormed` to support recording a function parameter, allowing us to get the corresponding HIR type if an error occurs. Function typechecking is modified to pass this information during signature normalization and WF checking. The resulting code is fairly verbose, due to the fact that we can no longer normalize the entire signature with a single function call. As part of the refactoring, we now perform HIR-based WF checking for several other 'typed items' (statics, consts, and inherent impls). As a result, WF and projection errors in a function signature now have a precise span, which points directly at the responsible type. If a function signature is constructed via a macro, this will allow the error message to point at the code 'most responsible' for the error (e.g. a user-supplied macro argument).
2021-07-20Auto merge of #87244 - jackh726:issue-71883, r=estebankbors-7/+15
Better diagnostics with mismatched types due to implicit static lifetime Fixes #78113 I think this is my first diagnostics PR...definitely happy to hear thoughts on the direction/implementation here. I was originally just trying to solve the error above, where the lifetime on a GAT was causing a cryptic "mismatched types" error. But as I was writing this, I realized that this (unintentionally) also applied to a different case: `wf-in-foreign-fn-decls-issue-80468.rs`. I'm not sure if this diagnostic should get a new error code, or even reuse an existing one. And, there might be some ways to make this even more generalized. Also, the error is a bit more lengthy and verbose than probably needed. So thoughts there are welcome too. This PR essentially ended up adding a new nice region error pass that triggers if a type doesn't match the self type of an impl which is selected because of a predicate because of an implicit static bound on that self type. r? `@estebank`
2021-07-19Better errors when we don't have implicit statics in trait objectsjackh726-1/+8
2021-07-19Better diagnostics when mismatched types due to implict static lifetimejackh726-8/+9
2021-07-18Extend HIR-based WF checking to associated type defaultsAaron Hill-4/+4
Previously, we would only look at associated types in `impl` blocks.
2021-07-16Add initial implementation of HIR-based WF checking for diagnosticsAaron Hill-2/+26
During well-formed checking, we walk through all types 'nested' in generic arguments. For example, WF-checking `Option<MyStruct<u8>>` will cause us to check `MyStruct<u8>` and `u8`. However, this is done on a `rustc_middle::ty::Ty`, which has no span information. As a result, any errors that occur will have a very general span (e.g. the definintion of an associated item). This becomes a problem when macros are involved. In general, an associated type like `type MyType = Option<MyStruct<u8>>;` may have completely different spans for each nested type in the HIR. Using the span of the entire associated item might end up pointing to a macro invocation, even though a user-provided span is available in one of the nested types. This PR adds a framework for HIR-based well formed checking. This check is only run during error reporting, and is used to obtain a more precise span for an existing error. This is accomplished by individually checking each 'nested' type in the HIR for the type, allowing us to find the most-specific type (and span) that produces a given error. The majority of the changes are to the error-reporting code. However, some of the general trait code is modified to pass through more information. Since this has no soundness implications, I've implemented a minimal version to begin with, which can be extended over time. In particular, this only works for HIR items with a corresponding `DefId` (e.g. it will not work for WF-checking performed within function bodies).
2021-07-09Replace associated item bound vars with placeholders when projecting.jackh726-2/+2
2021-05-21Adjust self-type to require equalityMark Rousskov-3/+31
2021-03-31give full path of constraint in suggest_constraining_type_paramhi-rustin-34/+34
revert file bless with nll mode
2021-03-15More precise spans for HIR pathsVadim Petrochenkov-1/+1