| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Make some diagnostics not depend on the source of what they reference being available
r? `@estebank`
follow up to https://github.com/rust-lang/rust/pull/104449
|
|
Synthesize a more accurate span and use verbose suggestion output to
make the message clearer.
|
|
available
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=cjgillot
gather body owners
Issue #96341
|
|
|
|
|
|
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
Suggest adding a `?Sized` bound if appropriate on E0599 by inspecting
the HIR Generics. (Fix #98539)
|
|
Shorten def_span for more items.
The `def_span` query only returns the signature span for functions.
Struct/enum/union definitions can also have a very long body.
This PR shortens the associated span.
|
|
|
|
Rewrite dead-code pass to avoid fetching HIR.
This allows to get a more uniform handling of spans, and to simplify the grouping of diagnostics for variants and fields.
|
|
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.
|
|
r=compiler-errors
Point to type parameter definition when not finding variant, method and associated item
fixes #77391
|
|
|
|
use `def_ident_span` , `body_owner_def_id` instead of `in_progress_typeck_results`, `guess_head_span`
use `body_id.owner` directly
add description to label
|
|
add comments in `store_dead_field_or_variant`
support multiple log level
add a item ident label
fix ui tests
fix a ui test
fix a rustdoc ui test
use let chain
refactor: remove `store_dead_field_or_variant`
fix a tiny bug
|
|
|
|
|
|
|
|
|
|
Properly track `ImplObligations`
Instead of probing for all possible `impl`s that could have caused an
`ImplObligation`, keep track of its `DefId` and obligation spans for
accurate error reporting.
Follow to #89580. Addresses #89418.
|
|
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.
|
|
|
|
danielhenrymantilla:diagnostics/union-drop-suggest-copy-bound-alternative, r=davidtwco
[diagnostics] Add mentions to `Copy` types being valid for `union` fields
This came up from some user on Discord which was using a `T : PrimitiveInt` generic type, and they wanted to use in a `union`. Rather than adding a `Copy` bound, they started pondering about the `ManuallyDrop<T>` road, and how to correctly use `unsafe` to perform the drops.
<img width="648" alt="Screen Shot 2022-02-15 at 22 28 34" src="https://user-images.githubusercontent.com/9920355/154152496-8f9be74b-ad59-4724-8f9e-48b446774e06.png">
- [Discord link](https://discord.com/channels/442252698964721669/443150878111694848/943092778534072320)
So, it seemed like the error message for types with potential drop glue on `union` fields could be improved to also mention the `Copy` alternative, since in many cases where `union`s are concerned, people are dealing with PODs / `Copy` types anyways 🙂
___
``@rustbot`` modify labels: +A-diagnostics +D-terse
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
This only applies to builtin derives as I don't think there is a
clean way to get the available derives in typeck.
Closes #85851
|
|
The definition order is already close to the span order, and only differs
in corner cases.
|
|
Previously, we would set up the source lines for `match` expressions so
that the code generated to perform the test of the scrutinee was matched
to the line of the arm that required the test and then jump from the arm
block to the "next" block was matched to all of the lines in the `match`
expression.
While that makes sense, it has the side effect of causing strange
stepping behavior in debuggers.
I've changed the source information so that all of the generated tests
are sourced to `match {scrutinee}` and the jumps are sourced to the last
line of the block they are inside. This resolves the weird stepping
behavior in all debuggers and resolves some instances of "ambiguous
symbol" errors in WinDbg preventing the user from setting breakpoints at
`match` expressions.
|
|
|
|
|
|
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
Assign E0784 error code for union expression errors
|
|
|