| Age | Commit message (Collapse) | Author | Lines |
|
Hidden suggestion support
Add way to hide suggestion snippet window from cli output to avoid cluttered spans that don't enhance understanding.
r? @pietroalbini CC @zackmdavis
|
|
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deduplicate mismatched delimiter errors
Delay unmatched delimiter errors until after the parser has run to deduplicate them when parsing and attempt recovering intelligently.
Second attempt at #54029, follow up to #53949. Fix #31528.
|
|
|
|
Delay unmatched delimiter errors until after the parser has run to
deduplicate them when parsing and attempt recovering intelligently.
|
|
|
|
|
|
|
|
The emitter already verifies wether a given span note or span label
can be emitted to the output. If it can't, because it is a dummy
span, it will be either elided for labels or emitted as an unspanned
note/help when applicable.
|
|
add applicability to remaining suggestions
Fixes #50723.
I noticed that the suggestion methods on `DiagnosticBuilder` weren't actually deprecated due to #57679. This PR deprecates them properly and fixes the remaining usages.
There's also a PR for clippy at rust-lang/rust-clippy#3667.
|
|
When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.
|
|
|
|
|
|
|
|
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
|
|
Replace usages of `..i + 1` ranges with `..=i`.
Before this change we were using old computer code techniques. After this change we use the new and improved computer code techniques.
|
|
fixes remaining test failures
|
|
|
|
|
|
Currently Cargo will always capture the output of rustc meaning that
rustc is never hooked up to a tty. To retain colors Cargo uses the
`fwdansi` crate to ensure that ansi color codes are translated to
windows terminal methods (and ansi codes otherwise just go their natural
route on Unix).
Cargo passes `--color always` to rustc to ensure that using a pipe
doesn't trick it into not emitting colors at all. It turns out, however,
that `--color always` ends up still accidentally using the native shell
api on native windows shells.
The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of
`Always`, ensuring that when `--color always` is passed to rustc and its
output isn't a terminal, we're always generating ansi colors regardless
of the platform.
Closes #55769
|
|
|
|
|
|
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
|
|
This is useful in debugging when and where errors are emitted in
logs.
|
|
|
|
|
|
diagnostics.
This is mainly intended for `rustc` developers who want to see a
diagnostic in its original context in the control flow. Two uses
cases for that are:
* `-Z treat-err-as-bug` which then allows extraction of a stack-trace to the origin of the error
(a case that is so important that we make that flag imply this one, effectively).
* `RUST_LOG=... rustc`, in which case it is often useful to see the logging statements that
occurred immediately prior to the point where the diagnostic was signalled.
Drive-by: Added some documentation pointing future devs at
HandlerFlags, and documented the fields of `HandlerFlags` itself.
|
|
|
|
|
|
|
|
|
|
|
|
Fix compiling some rustc crates to wasm
I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:
* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
platforms.
In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!
|
|
Co-authored-by: nikomatsakis
|
|
I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:
* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
platforms.
In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!
|
|
|