| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This makes `Handler::fatal` more like `Handler::{err,warn,bug,note}`.
|
|
|
|
This is weird: `HandlerInner::emit` calls
`HandlerInner::emit_diagnostic`, but only after doing a
`treat-err-as-bug` check. Which is fine, *except* that there are
multiple others paths for an `Error` or `Fatal` diagnostic to be passed
to `HandlerInner::emit_diagnostic` without going through
`HandlerInner::emit`, e.g. `Handler::span_err` call
`Handler::emit_diag_at_span`, which calls `emit_diagnostic`.
So that suggests that the coverage for `treat-err-as-bug` is incomplete.
This commit removes `HandlerInner::emit` and moves the
`treat-err-as-bug` check to `HandlerInner::emit_diagnostic`, so it
cannot by bypassed.
|
|
`Handler` is a wrapper around `HanderInner`. Some functions on
on `Handler` just forward to the samed-named functions on
`HandlerInner`.
This commit removes as many of those as possible, implementing functions
on `Handler` where possible, to avoid the boilerplate required for
forwarding. The commit is moderately large but it's very mechanical.
|
|
By making it generic, instead of only for `EmissionGuarantee = ()`, we
can use it everywhere.
|
|
They each have a single call site.
Note: the `make_diagnostic_builder` calls in `lib.rs` will be replaced
in a subsequent commit.
|
|
Currently, `Handler::fatal` returns `FatalError`. But `Session::fatal`
returns `!`, because it calls `Handler::fatal` and then calls `raise` on
the result. This inconsistency is unfortunate.
This commit changes `Handler::fatal` to do the `raise` itself, changing
its return type to `!`. This is safe because there are only two calls to
`Handler::fatal`, one in `rustc_session` and one in
`rustc_codegen_cranelift`, and they both call `raise` on the result.
`HandlerInner::fatal` still returns `FatalError`, so I renamed it
`fatal_no_raise` to emphasise the return type difference.
|
|
- Avoid unnecessary `inner` local variables.
- Use `borrow_mut` everywhere (instead of the synonym `lock`).
|
|
In line with the previous commits.
|
|
For reasons similar to the previous commit.
|
|
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug`
follows the pattern used everywhere else: `span_err`, `span_warning`,
etc.
|
|
Because the variant name in `Level` is `Note`, and the `without_error`
suffix is omitted in similar cases like `struct_allow` and
`struct_help`.
|
|
To match the `FailureNote` variant of `Level`.
|
|
Because `span_note_diag` doesn't follow the naming structure used for
the error reporting functions.
|
|
|
|
`ErrorGuaranteed` should be used for all error methods involving the
`Error` level, e.g. as is done for the corresponding `span_err` methods.
|
|
Currently we always do this:
```
use rustc_fluent_macro::fluent_messages;
...
fluent_messages! { "./example.ftl" }
```
But there is no need, we can just do this everywhere:
```
rustc_fluent_macro::fluent_messages! { "./example.ftl" }
```
which is shorter.
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
|
|
Stabilize `result_option_inspect`
This PR stabilizes `result_option_inspect`:
```rust
// core::option
impl Option<T> {
pub fn inspect<F: FnOnce(&T)>(self, f: F) -> Self;
}
// core::result
impl Result<T, E> {
pub fn inspect<F: FnOnce(&T)>(self, f: F) -> Self;
pub fn inspect_err<F: FnOnce(&E)>(self, f: F) -> Self;
}
```
<br>
Tracking issue: https://github.com/rust-lang/rust/issues/91345.
Implementation PR: https://github.com/rust-lang/rust/pull/91346.
Closes https://github.com/rust-lang/rust/issues/91345.
|
|
|
|
|
|
|
|
Suggest adding `return` if the for semi which can coerce to the fn return type
Fixes #86094
r? `@estebank`
|
|
to the fn return type
|
|
|
|
|
|
|
|
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
Use `Freeze` for `SourceFile`
This uses the `Freeze` type in `SourceFile` to let accessing `external_src` and `lines` be lock-free.
Behavior of `add_external_src` is changed to set `ExternalSourceKind::AbsentErr` on a hash mismatch which matches the documentation. `ExternalSourceKind::Unneeded` was removed as it's unused.
Based on https://github.com/rust-lang/rust/pull/115401.
|
|
|
|
|
|
|
|
As suggested in https://github.com/rust-lang/rust/pull/115393, add a comment so someone doesn't clean these up.
|
|
After https://github.com/rust-lang/rust/pull/114104, `rust-gpu` is unable to create a custom `Emitter` as the bounds have changed to include `WriteColor`.
I was able to work around this by adding `termcolor` as a direct dependency, but I believe this should be exposed as part of `rustc_errors` proper.
See https://github.com/rust-lang/rust/pull/102992 for why `rust-gpu` needs to create a custom emitter.
|
|
|
|
|
|
|
|
|
|
|
|
Lots of tiny incremental simplifications of `EmitterWriter` internals
ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version.
Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them.
After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
|
|
|
|
fix(resolve): update the ambiguity glob binding as warning recursively
Fixes #47525
Fixes #56593, but `issue-56593-2.rs` is not fixed to ensure backward compatibility.
Fixes #98467
Fixes #105235
Fixes #112713
This PR had added a field called `warn_ambiguous` in `NameBinding` which is only for back compatibly reason and used for lint.
More details: https://github.com/rust-lang/rust/pull/112743
r? `@petrochenkov`
|
|
When flushing delayed span bugs, write to the ICE dump file even if it doesn't exist
Fix #113881.
|
|
|
|
doesn't exist
Fix #113881.
|
|
Implement diagnostic translation for rustc-errors
This is my first PR to rustc yeah~
I'm going to implement diagnostic translation on rustc-errors crate.
This PR is WIP, the reason of opening this as draft, I want to show my code to prevent the issue caused by misunderstanding and also I have few questions.
Some error messages are processed by `pluralize!` macro which determines to use plural word or not. From now, I make two kinds of keys and combine with enum but I'm not sure is this best method to do it.
Is there any prefered method to do this? => This resolved on conversation on PR.
I'll remain to perform force-push until my first implementation looks good to me
|
|
|
