Trigger `unsafe_code` lint on invocations of `global_asm`
`unsafe_code` already warns about things that don't involve the `unsafe` keyword, e.g. `#[no_mangle]`. This makes it warn on `core::arch::global_asm` too.
Fixes#103078
Rename `ConstPropLint` to `KnownPanicsLint`
`OverflowLint` is a clearer name because it communicates what the lint does instead of the underlying mechanism it uses (const propagation) which should be of secondary concern.
`OverflowLint` isn't the most accurate name because the lint looks for other errors as well such as division by zero not just overflows, but I couldn't think of another equally succinct name.
As a part of this change. I've also added/updated some of the comments.
cc ```@RalfJung``` ```@oli-obk``` for visibility in case you go looking for the lint using the old name.
Edit:
Changed the name from `OverflowLint` to `KnownPanicsLint`
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.
When shortening the type it is necessary to take into account the
`--verbose` flag, if it is activated, we must always show the entire
type and not write it in a file.
Fixes: https://github.com/rust-lang/rust/issues/119130
Rollup of 10 pull requests
Successful merges:
- #120716 (Change leak check and suspicious auto trait lint warning messages)
- #121195 (unstable-book: Separate testing and production sanitizers)
- #121205 (Merge `CompilerError::CompilationFailed` and `CompilerError::ICE`.)
- #121233 (Move the extra directives for `Mode::CoverageRun` into `iter_header`)
- #121256 (Allow AST and HIR visitors to return `ControlFlow`)
- #121307 (Drive-by `DUMMY_SP` -> `Span` and fmt changes)
- #121308 (Add regression test for #103369)
- #121310 (Remove an old hack for rustdoc)
- #121311 (Make `is_nonoverlapping` `#[inline]`)
- #121319 (return `ty::Error` when equating `ty::Error`)
r? `@ghost`
`@rustbot` modify labels: rollup
return `ty::Error` when equating `ty::Error`
This helps iron out a difference in diagnostics between `Sub` and `Equate` relations, which I'm currently trying to unify.
r? oli-obk
Drive-by `DUMMY_SP` -> `Span` and fmt changes
Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.
Allow AST and HIR visitors to return `ControlFlow`
Alternative to #108598.
Since rust-lang/libs-team#187 was rejected, this implements our own version of the `Try` trait (`VisitorResult`) and the `try` macro (`try_visit`). Since this change still allows visitors to return `()`, no changes have been made to the existing ones. They can be done in a separate PR.
Merge `CompilerError::CompilationFailed` and `CompilerError::ICE`.
`CompilerError` has `CompilationFailed` and `ICE` variants, which seems reasonable at first. But the way it identifies them is flawed:
- If compilation errors out, i.e. `RunCompiler::run` returns an `Err`, it uses `CompilationFailed`, which is reasonable.
- If compilation panics with `FatalError`, it catches the panic and uses `ICE`. This is sometimes right, because ICEs do cause `FatalError` panics, but sometimes wrong, because certain compiler errors also cause `FatalError` panics. (The compiler/rustdoc/clippy/whatever just catches the `FatalError` with `catch_with_exit_code` in `main`.)
In other words, certain non-ICE compilation failures get miscategorized as ICEs. It's not possible to reliably distinguish the two cases, so this commit merges them. It also renames the combined variant as just `Failed`, to better match the existing `Interrupted` and `Skipped` variants.
Here is an example of a non-ICE failure that causes a `FatalError` panic, from `tests/ui/recursion_limit/issue-105700.rs`:
```
#![recursion_limit="4"]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
//~^ERROR recursion limit reached while expanding
fn main() {{}}
```
r? ``@spastorino``
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
pattern_analysis: Move constructor selection logic to `PlaceInfo`
This is a small refactor PR. There was a dense bit of constructor-related logic in `compute_exhaustiveness_and_usefulness`. I'm moving it out into a `PlaceInfo` method to make it easier to follow both separately. I also have plans that will complicate it further so it's good that it's somewhat encapsulated.
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.
Fix `IPHONEOS_DEPLOYMENT_TARGET` on Mac Catalyst
Some of the target code invalidly assumed that the deployment target variable on Mac Catalyst is `MACOSX_DEPLOYMENT_TARGET`, which is wrong, Mac Catalyst uses the same environment variable as iOS.
Additionally, the deployment target was hardcoded to `14.0`, I've lowered this to `13.1` ([same default as Clang](d022f32c73/clang/lib/Driver/ToolChains/Darwin.cpp (L2038))), and made it properly load from the environment.
This shouldn't require any changes to the `cc` crate, as that uses `rustc --print=deployment-target` to get this information automatically.
CC `@BlackHoleFox`
r? `@rust-lang/macos`
deduplicate infer var instantiation
Having 3 separate implementations of one of the most subtle parts of our type system is not a good strategy if we want to maintain a sound type system ✨ while working on this I already found some subtle bugs in the existing code, so that's awesome 🎉 cc #121159
This was necessary as I am not confident in my nll changes in #119106, so I am first cleaning this up in a separate PR.
r? `@BoxyUwU`
This change was prompted by the stage1 compiler spending 4% of its time
when compiling the polymorphic-recursion MIR opt test in `unlikely`.
Intrinsic fallback bodies like `unlikely` should always be inlined, it's
very silly if they are not. To do this, we enable the fallback bodies to
be cross-crate inlineable. Not that this matters for our workloads since
the compiler never actually _uses_ the "fallback bodies", it just uses
whatever was cfg(bootstrap)ped, so I've also added `#[inline]` to those.
Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.
some trait system cleanups
Always eagerly replace projections with infer vars if normalization is ambig. Unsure why we previously didn't do so, wasn't able to find an explanation in #90887. This adds some complexity to the trait system and is afaict unnecessary.
The second commit simplifies `pred_known_to_hold_modulo_regions`, afaict the optional `fulfill` isn't necessary anymore.
r? types cc `@jackh726`
