Remove the "codegen" profile from bootstrap
This profile originally made sense when download-ci-llvm = if-unchanged didn't exist and we had the bad tradeoff of "never modify or always compile".
Thankfully, these grim times are over and we have discovered clean water, so the only differentiator between the two profiles is the codegen profile having LLVM assertions. Adding them doesn't cause that much of a slowdown, <10% on UI tests from an unscientific benchmark.
It also had LLVM warnings when compiling, which makes sense for every compiler contributor brave enough to compile LLVM.
The way I removed is by just issueing a nice error message. Given that everyone with this profile should be a contributor and not someone like a distro who is more upset when things break, this should be fine. If it isn't, we can always fall back to just letting codegen mean compiler.
Overhaul `Diagnostic` and `DiagnosticBuilder`
Implements the first part of https://github.com/rust-lang/compiler-team/issues/722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`.
Likely follow-ups:
- Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`.
- Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`.
r? `@davidtwco`
Always evaluate free constants and statics, even if previous errors occurred
work towards https://github.com/rust-lang/rust/issues/79738
We will need to evaluate static items before the `definitions.freeze()` below, as we will start creating new `DefId`s (for nested allocations) within the `eval_static_initializer` query.
But even without that motivation, this is a good change. Hard errors should always be reported and not silenced if other errors happened earlier.
Move the extra directives for `Mode::CoverageRun` into `iter_header`
When these extra directives were ported over as part of #112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument.
But now that #120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
unstable-book: Separate testing and production sanitizers
This is a redo of [this PR](https://github.com/rust-lang/rust/pull/108942). Left the commit as before (except for reflowing to 80-width), since it already got approved.
Change leak check and suspicious auto trait lint warning messages
The leak check lint message "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!" is misleading as some cases may not be phased out and could end being accepted. This is under discussion still.
The suspicious auto trait lint the change in behavior already happened, so the new message is probably more accurate.
r? `@lcnr`
Closes#93367
Reimpl meaningful test name lint MCP658
This reintroduces the tidy rule originally proposed in https://github.com/rust-lang/rust/pull/113583 that then became an MCP in https://github.com/rust-lang/compiler-team/issues/658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this:
```
tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs`
tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs`
tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs`
tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs`
tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
```
You get the idea.
There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like:
- issue-314159265-blue.rs
- issue-314159265-red.rs
Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be:
- colored-circle-gen-blue.rs
- colored-circle-gen-red.rs
Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what.
r? `@compiler-errors`
Currently many diagnostic modifier methods are available on both
`Diagnostic` and `DiagnosticBuilder`. This commit removes most of them
from `Diagnostic`. To minimize the diff size, it keeps them within
`diagnostic.rs` but changes the surrounding `impl Diagnostic` block to
`impl DiagnosticBuilder`. (I intend to move things around later, to give
a more sensible code layout.)
`Diagnostic` keeps a few methods that it still needs, like `sub`,
`arg`, and `replace_args`.
The `forward!` macro, which defined two additional methods per call
(e.g. `note` and `with_note`), is replaced by the `with_fn!` macro,
which defines one additional method per call (e.g. `with_note`). It's
now also only used when necessary -- not all modifier methods currently
need a `with_*` form. (New ones can be easily added as necessary.)
All this also requires changing `trait AddToDiagnostic` so its methods
take `DiagnosticBuilder` instead of `Diagnostic`, which leads to many
mechanical changes. `SubdiagnosticMessageOp` gains a type parameter `G`.
There are three subdiagnostics -- `DelayedAtWithoutNewline`,
`DelayedAtWithNewline`, and `InvalidFlushedDelayedDiagnosticLevel` --
that are created within the diagnostics machinery and appended to
external diagnostics. These are handled at the `Diagnostic` level, which
means it's now hard to construct them via `derive(Diagnostic)`, so
instead we construct them by hand. This has no effect on what they look
like when printed.
There are lots of new `allow` markers for `untranslatable_diagnostics`
and `diagnostics_outside_of_impl`. This is because
`#[rustc_lint_diagnostics]` annotations were present on the `Diagnostic`
modifier methods, but missing from the `DiagnosticBuilder` modifier
methods. They're now present.
This profile originally made sense when download-ci-llvm = if-unchanged
didn't exist and we had the bad tradeoff of "never modify or always
compile".
Thankfully, these grim times are over and we have discovered clean
water, so the only differentiator between the two profiles is the
codegen profile having LLVM assertions. Adding them doesn't cause that
much of a slowdown, <10% on UI tests from an unscientific benchmark.
It also had LLVM warnings when compiling, which makes sense for every
compiler contributor brave enough to compile LLVM.
The way I removed is by just issueing a nice error message. Given that
everyone with this profile should be a contributor and not someone like
a distro who is more upset when things break, this should be fine.
If it isn't, we can always fall back to just letting codegen mean
compiler.
distribute tool documentations and avoid file conflicts on `x install`
I suggest reading commits one-by-one with the descriptions for more context about the changes.
Fixes#115213
There are lots of functions that modify a diagnostic. This can be via a
`&mut Diagnostic` or a `&mut DiagnosticBuilder`, because the latter type
wraps the former and impls `DerefMut`.
This commit converts all the `&mut Diagnostic` occurrences to `&mut
DiagnosticBuilder`. This is a step towards greatly simplifying
`Diagnostic`. Some of the relevant function are made generic, because
they deal with both errors and warnings. No function bodies are changed,
because all the modifier methods are available on both `Diagnostic` and
`DiagnosticBuilder`.
Reduce monomorphisation bloat in small_c_string
This is a code path usually next to an FFI call, so taking the `dyn` slowdown for the 1159 llvm-line (fat lto, codegen-units 1, release build) drop in my testing program [t2fanrd](https://github.com/GnomedDev/t2fanrd) is worth it imo.
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
rustdoc: fix and refactor HTML rendering a bit
* refactoring: get rid of a bunch of manual `f.alternate()` branches
* not sure why this wasn't done so already, is this perf-sensitive?
* fix an ICE in debug builds of rustdoc
* rustdoc used to crash on empty outlives-bounds: `where 'a:`
* properly escape const generic defaults
* actually print empty trait and outlives-bounds (doesn't work for cross-crate reexports yet, will fix that at some other point) since they can have semantic significance
* outlives-bounds: forces lifetime params to be early-bound instead of late-bound which is technically speaking part of the public API
* trait-bounds: can affect the well-formedness, consider
* makeshift “const-evaluatable” bounds under `generic_const_exprs`
* bounds to force wf-checking in light of #100041 (quite artificial I know, I couldn't figure out something better), see https://github.com/rust-lang/rust/pull/121160#discussion_r1491563816
When these extra directives were ported over as part of #112300, it made sense
to introduce `iter_header_extra` and pass them in as an extra argument.
But now that #120881 has added a `mode` parameter to `iter_header` for its own
purposes, it's slightly simpler to move the coverage special-case code directly
into `iter_header` as well. This lets us get rid of `iter_header_extra`.
As the reason for tidy failing the test name may seem slightly opaque,
provide a suggestion on how to rename the file.
There are some tests which merely would require reordering of the name
according to the rule. I could modify the diagnostic further to identify
those, but doing such would make it prone to bad suggestions. I have opted
to trust contributors to recognize the diagnostic is robotic, as the
pattern we are linting on is easier to match if we do not speculate on what
parts of the name are meaningful: sometimes a word is a reason, but
sometimes it is a mere "tag", such as with a pair like:
issue-314159265-blue.rs
issue-314159265-red.rs
Starting them with `red-` and `blue-` means they do not sort together,
despite being related, and the color names are still not very descriptive.
Recognizing a good name is an open-ended task, though this pair might be:
colored-circle-gen-blue.rs
colored-circle-gen-red.rs
Deciding exactly how to solve this is not the business of tidy,
only recognizing a what.
