| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove `PErr`.
It's just a synonym for `Diag` that adds no value and is only used in a few places.
r? ``@spastorino``
|
|
suppress field expr with generics error message if it's a method
Don't emit "field expressions may not have generic arguments" if it's a method call without `()`
r? estebank
Fixes #67680
Is this the best way to go? It's by far the simplest I could come up with.
|
|
It's just a synonym for `Diag` that adds no value and is only used in a
few places.
|
|
method call without ()
|
|
|
|
delayed bugs
|
|
And pass this to the individual emitters when necessary.
|
|
|
|
Avoid `&Lrc<T>` in various places
Seeing `&Lrc<T>` is a bit suspicious, and `&T` or `Lrc<T>` is often better.
r? `@oli-obk`
|
|
It's simpler and more concise.
|
|
It's no longer used meaningfully.
This also means `DiagCtxtHandle::err_count_excluding_lint_errs` can be
removed.
|
|
|
|
|
|
|
|
|
|
|
|
r=compiler-errors,jieyouxu
chore: Fix typos in 'compiler' (batch 1)
Batch 1/3: Fixes typos in `compiler`
(See [issue](https://github.com/rust-lang/rust/issues/129874) tracking all PRs with typos fixes)
|
|
|
|
|
|
|
|
|
|
|
|
Use `assert_matches` around the compiler more
It's a useful assertion, especially since it actually prints out the LHS.
|
|
|
|
|
|
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.
Fix clippy lint suggestion incorrectly treated as `span_help`.
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
Support lists and stylings in more places for `rustc --explain`
Adds support for `*foo*`, stylings not immediately following whitespace e.g. ``(`Foo`)`` and lists starting with whitespace:
```md
* previously supported
```
```md
* now also supported
```
These are fairly common in the existing error docs, some before/after examples:
### E0460
### E0059
|
|
|
|
|
|
|
|
Very similar to #126719. So much so that I added a new case to the test
from that PR rather than creating a new one.
|
|
In #120699 I moved some code dealing with `has_future_breakage` earlier
in `emit_diagnostic`. Issue #126521 identified a case where that
reordering was invalid (leading to an assertion failure) for some `Expect`
diagnostics.
This commit partially undoes the change, by moving the handling of
unstable `Expect` diagnostics earlier again. This makes
`emit_diagnostic` a bit uglier, but is necessary to fix the problem.
Fixes #126521.
|
|
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
|
|
With the removal of `LintDiagnostic::msg` / the `msg` param from
lint diag APIs, primary messages for lint diags are always constructed
lazily inside decorator fns rendering this wrapper type unused / useless.
|
|
|
|
|
|
|
|
Allow nesting subdiagnostics in #[derive(Subdiagnostic)]
|
|
|
|
This requires nested subdiagnostics.
|
|
We want to run them on all 64-bit platforms.
|
|
Check `x86_64` size assertions on `aarch64`, too
(Context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Checking.20size.20assertions.20on.20aarch64.3F)
Currently the compiler has around 30 sets of `static_assert_size!` for various size-critical data structures (e.g. various IR nodes), guarded by `#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]`.
(Presumably this cfg avoids having to maintain separate size values for 32-bit targets and unusual 64-bit targets. Apparently it may have been necessary before the i128/u128 alignment changes, too.)
This is slightly incovenient for people on aarch64 workstations (e.g. Macs), because the assertions normally aren't checked until we push to a PR. So this PR adds `aarch64` to the `#[cfg(..)]` guarding all of those assertions in the compiler.
---
Implemented with a simple find/replace. Verified by manually inspecting each `static_assert_size!` in `compiler/`, and checking that either the replacement succeeded, or adding aarch64 wouldn't have been appropriate.
|
|
Better reporting on generic argument mismatchs
This allows better reporting as per issue #116615 .
If you have a function:
```
fn foo(a: T, b: T) {}
```
and call it like so:
```
foo(1, 2.)
```
it'll give improved error reported similar to the following:
```
error[E0308]: mismatched types
--> generic-mismatch-reporting-issue-116615.rs:6:12
|
6 | foo(1, 2.);
| --- - ^^ expected integer, found floating-point number
| | |
| | expected argument `b` to be an integer because that argument needs to match the type of this parameter
| arguments to this function are incorrect
|
note: function defined here
--> generic-mismatch-reporting-issue-116615.rs:1:4
|
1 | fn foo<T>(a: T, b: T) {}
| ^^^ - ---- ----
| | | |
| | | this parameter needs to match the integer type of `a`
| | `b` needs to match the type of this parameter
| `a` and `b` all reference this parameter T
```
Open question, do we need to worry about error message translation into other languages? Not sure what the status of that is in Rust.
NB: Needs some checking over and some tests have altered that need sanity checking, but overall this is starting to get somewhere now. Will take out of draft PR status when this has been done, raising now to allow feedback at this stage, probably 90% ready.
|
|
This makes it easier for contributors on aarch64 workstations (e.g. Macs) to
notice when these assertions have been violated.
|
|
r=davidtwco
conditionally ignore fatal diagnostic in the SilentEmitter
This change is primarily meant to allow rustfmt to ignore all diagnostics when using the `SilentEmitter`. Back in #121301 the `SilentEmitter` was shared between rustc and rustfmt. This changed rustfmt's behavior from ignoring all diagnostic to emitting fatal diagnostics, which lead to https://github.com/rust-lang/rustfmt/issues/6109.
These changes allow rustfmt to maintain its previous behaviour when using the `SilentEmitter`, while allowing rustc code to still emit fatal diagnostics.
|
|
|
|
This change is primarily meant to allow rustfmt to ignore all
diagnostics when using the `SilentEmitter`. Back in PR 121301 the
`SilentEmitter` was shared between rustc and rustfmt. This changed
rustfmt's behavior from ignoring all diagnostic to emitting fatal
diagnostics.
These changes allow rustfmt to maintain it's previous behaviour when
using the SilentEmitter, while allowing rustc code to still emit fatal
diagnostics.
|
|
- Firstly get all the information about generics matching out of the HIR
- Secondly the labelling for the function is more coherent now
- Lastly a few error message improvements
|
|
Needs some checking over and some tests have altered that need sanity checking, but overall this is starting to get somewhere now.
|
