Reenable generator drop tracking tests and fix mutation handling
The previous PR, #94068, was overly zealous in counting mutations as borrows, which effectively nullified drop tracking. We would have caught this except the drop tracking tests were still ignored, despite having the option of using the `-Zdrop-tracking` flag now.
This PR fixes the issue introduced by #94068 by only counting mutations as borrows the mutated place has a project. This is sufficient to distinguish `x.y = 42` (which should count as a borrow of `x`) from `x = 42` (which is not a borrow of `x` because the whole variable is overwritten).
This PR also re-enables the drop tracking regression tests using the `-Zdrop-tracking` flag so we will avoid introducing these sorts of issues in the future.
Thanks to ``@tmiasko`` for noticing this problem and pointing it out!
r? ``@tmiasko``
Do not point at whole file missing `fn main`
Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.
This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.
Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.
This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.
Rollup of 5 pull requests
Successful merges:
- #94362 (Add well known values to `--check-cfg` implementation)
- #94577 (only disable SIMD for doctests in Miri (not for the stdlib build itself))
- #94595 (Fix invalid `unresolved imports` errors for a single-segment import)
- #94596 (Delay bug in expr adjustment when check_expr is called multiple times)
- #94618 (Don't round stack size up for created threads in Windows)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This keeps `reason` around for the time being. This is necessary to
avoid breakage during the bootstrap process. This change, as a whole,
brings `#[rustc_deprecated]` more in line with `#[deprecated]`.
Delay bug in expr adjustment when check_expr is called multiple times
Instead of including slightly more complicated logic in `check_argument_types` to fix the bug (#94516) I introduced in #94438, and inevitably have this bug appear once again when some other diagnostic is written that causes `check_expr` to be called an expression during a (bad) code path, just delay the bug in adjustment logic.
I am open to other implementations that don't delay the bug here.
Fixes#94516
Add well known values to `--check-cfg` implementation
This pull-request adds well known values for the well known names via `--check-cfg=values()`.
[RFC 3013: Checking conditional compilation at compile time](https://rust-lang.github.io/rfcs/3013-conditional-compilation-checking.html#checking-conditional-compilation-at-compile-time) doesn't define this at all, but this seems a nice improvement.
The activation is done by a empty `values()` (new syntax) similar to `names()` except that `names(foo)` also activate well known names while `values(aa, "aa", "kk")` would not.
As stated this use a different activation logic because well known values for the well known names are not always sufficient.
In fact this is problematic for every `target_*` cfg because of non builtin targets, as the current implementation use those built-ins targets to create the list the well known values.
The implementation is straight forward, first we gather (if necessary) all the values (lazily or not) and then we apply them.
r? ```@petrochenkov```
Enable conditional compilation checking on the Rust codebase
This pull-request enable conditional compilation checking on every rust project build by the `bootstrap` tool.
To be more specific, this PR only enable well known names checking + extra names (bootstrap, parallel_compiler, ...).
r? `@Mark-Simulacrum`
Remove num_cpus dependency from bootstrap, build-manifest and rustc_s…
…ession
`std::threads::available_parallelism` was stabilized in rust 1.59.
r? ```````````````````````````@Mark-Simulacrum```````````````````````````
This ensures that information about target features configured with
`-C target-feature=...` or detected with `-C target-cpu=native` is
retained for subsequent consumers of LLVM bitcode.
This is crucial for linker plugin LTO, since this information is not
conveyed to the plugin otherwise.
Add !align metadata on loads of &/&mut/Box
Note that this refers to the alignment of what the loaded value points
to, _not_ the alignment of the loaded value itself.
r? `@ghost` (blocked on #94158)
Ensure stability directives are checked in all cases
Split off #93017
Stability and deprecation were not checked in all cases, for instance if a type error happened.
This PR moves the check earlier in the pipeline to ensure the errors are emitted in all cases.
r? `@lcnr`
Make Ord and PartialOrd opt-out in `newtype_index`
Part of work on #90317. This will allow us to do
```diff
rustc_index::newtype_index! {
/// A unique ID associated with a macro invocation and expansion.
pub struct LocalExpnId {
ENCODABLE = custom
DEBUG_FORMAT = "expn{}"
+ ORD_IMPL = off
}
}
```
ARM: Only allow using d16-d31 with asm! when supported by the target
Support can be determined by checking for the "d32" LLVM feature.
r? ```````````````@nagisa```````````````
Generalize get_nullable_type to accept types that have an all-ones bit
pattern as their sentry "null" value.
This will allow [`OwnedFd`], [`BorrowedFd`], [`OwnedSocket`], and
[`BorrowedSocket`] to be marked with
`#[rustc_nonnull_optimization_guaranteed]`, which will allow
`Option<OwnedFd>`, `Option<BorrowedFd>`, `Option<OwnedSocket>`, and
`Option<BorrowedSocket>` to be used in FFI declarations, as described
in the [I/O safety RFC].
For example, it will allow a function like `open` on Unix and `WSASocketW`
on Windows to be declared using `Option<OwnedFd>` and `Option<OwnedSocket>`
return types, respectively.
The actual change to add `#[rustc_nonnull_optimization_guaranteed]`
to the abovementioned types will be a separate PR, as it'll depend on
having this patch in the stage0 compiler.
Also, update the diagnostics to mention that "niche optimizations" are
used in libstd as well as libcore, as `rustc_layout_scalar_valid_range_start`
and `rustc_layout_scalar_valid_range_end` are already in use in libstd.
[`OwnedFd`]: c9dc44be24/library/std/src/os/fd/owned.rs (L49)
[`BorrowedFd`]: c9dc44be24/library/std/src/os/fd/owned.rs (L29)
[`OwnedSocket`]: c9dc44be24/library/std/src/os/windows/io/socket.rs (L51)
[`BorrowedSocket`]: c9dc44be24/library/std/src/os/windows/io/socket.rs (L29)
[I/O safety RFC]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md#ownedfd-and-borrowedfdfd-1
then we just suggest the first legal position where you could inject a use.
To do this, I added `inject_use_span` field to `ModSpans`, and populate it in
parser (it is the span of the first token found after inner attributes, if any).
Then I rewrote the use-suggestion code to utilize it, and threw out some stuff
that is now unnecessary with this in place. (I think the result is easier to
understand.)
Then I added a test of issue 87613.
Fix invalid lint_node_id being put on a removed stmt
This pull-request remove a invalid `assign_id!` being put on an stmt node.
The problem is that this node is being removed away by a cfg making it unreachable when triggering a buffered lint.
The comment in the other match arm already tell to not assign a id because it could have a `#[cfg()]` so this is just respecting the comment.
Fixes https://github.com/rust-lang/rust/issues/94523
r? ```````@petrochenkov```````
improve comments for `simplify_type`
Should now correctly describe what's going on. Experimented with checking the invariant for projections
but that ended up requiring fairly involved changes. I assume that it is not possible to get unsoundness here,
at least for now and I can pretty much guarantee that it's impossible to trigger it by accident.
r? `````@nikomatsakis````` cc #92721
Implementation of the `expect` attribute (RFC 2383)
This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute.
### Example
#### input
```rs
// required feature flag
#![feature(lint_reasons)]
#[expect(unused_mut)] // Will warn about an unfulfilled expectation
#[expect(unused_variables)] // Will be fulfilled by x
fn main() {
let x = 0;
}
```
#### output
```txt
warning: this lint expectation is unfulfilled
--> $DIR/trigger_lint.rs:3:1
|
LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation
| ^^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
```
### Implementation
This implementation introduces `Expect` as a new lint level for diagnostics, which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query.
The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission, while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise, a new lint message will be emitted.
The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage, it's not possible to create a stable identifier. The level instead stores an unstable identifier, which is later converted to a stable `LintExpectationId`.
### Followup TO-DOs
All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them:
* [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute.
* This should be easily possible, but I wanted to get some feedback before putting more work into this.
* This could also be done in a new PR to not add to much more code to this one
* [ ] Update unstable documentation to reflect this change.
* [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics)
### Open questions
I also have a few open questions where I would like to get feedback on:
1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091), suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion, or was this discarded with the merge of the RFC?
2. How should the expect attribute deal with the new `force-warn` lint level?
---
This approach was inspired by a discussion with `@LeSeulArtichaut.`
RFC tracking issue: #54503
Mentoring/Implementation issue: #85549
[`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html
[`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html
[`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels
[`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html
[`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html
remove obligation dedup from `impl_or_trait_obligations`
Looking at the examples from #38528 they all seem to compile fine even without this and it seems like this might be unnecessary effort
Miri/CTFE: properly treat overflow in (signed) division/rem as UB
To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.
r? `@oli-obk`
There are three `Option` fields in `MatcherPos` that are only used in
tandem. This commit combines them, making the code slightly easier to
read. (It also makes clear that the `sep` field arguably should have
been `Option<Option<Token>>`!)
To avoid the strange style where comments force `else` onto its own
line.
The commit also removes several else-after-return constructs, which can
be hard to read.
Remove out-of-context line at end of E0284 message
Removed the last line of E0284 message because it was out of context (probably kept by accident when changing whole error message).
Restore the local filter on mono item sorting
In `CodegenUnit::items_in_deterministic_order`, there's a comment that
only local HirIds should be taken into account, but #90408 removed the
`as_local` call that sets others to None. Restoring that check fixes the
s390x hangs seen in [RHBZ 2058803].
[RHBZ 2058803]: https://bugzilla.redhat.com/show_bug.cgi?id=2058803
Improve allowness of the unexpected_cfgs lint
This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.
Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.
Found while working on https://github.com/rust-lang/rust/pull/94298.
r? ````````@petrochenkov````````
Adt copy suggestions
Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type params
i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest anything for `Option<String>`.
An example:
```rust
fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
(t, t)
}
```
New error (current compiler doesn't provide `help`:):
```text
error[E0382]: use of moved value: `t`
--> t.rs:2:9
|
1 | fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
| - move occurs because `t` has type `Option<T>`, which does not implement the `Copy` trait
2 | (t, t)
| - ^ value used here after move
| |
| value moved here
|
help: consider restricting type parameter `T`
|
1 | fn duplicate<T: Copy>(t: Option<T>) -> (Option<T>, Option<T>) {
| ++++++
```
Fixes#93623
r? ``````````@estebank``````````
``````````@rustbot`````````` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement
----
I'm not at all sure if this is the right implementation for this kind of suggestion, but it seems to work :')
* Add UI tests with macros for the `expect` attribute (RFC-2383)
* Addressed review comments - mostly UI test updates (RFC-2383)
* Documented lint level attribute on macro not working bug (RFC-2383)
See `rust#87391`
Remove LLVM attribute removal
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function.
Then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
(see [`src/test/codegen/optimize-attr-1.rs`](03a8cc7df1/src/test/codegen/optimize-attr-1.rs (L33)))
However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
r? `@ghost` (blocked on #94221)
`@rustbot` label S-blocked
Rollup of 9 pull requests
Successful merges:
- #94464 (Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.)
- #94476 (7 - Make more use of `let_chains`)
- #94478 (Fix panic when handling intra doc links generated from macro)
- #94482 (compiler: fix some typos)
- #94490 (Update books)
- #94496 (tests: accept llvm intrinsic in align-checking test)
- #94498 (9 - Make more use of `let_chains`)
- #94503 (Provide C FFI types via core::ffi, not just in std)
- #94513 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.
Suggest adding a new lifetime parameter when two elided lifetimes should match up for functions in traits and impls.
Issue #94462
Direct users towards using Rust target feature names in CLI
This PR consists of a couple of changes on how we handle target features.
In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed).
The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery. And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me.
Sponsored by: standard.ai
In `CodegenUnit::items_in_deterministic_order`, there's a comment that
only local HirIds should be taken into account, but #90408 removed the
`as_local` call that sets others to None. Restoring that check fixes the
s390x hangs seen in [RHBZ 2058803].
[RHBZ 2058803]: https://bugzilla.redhat.com/show_bug.cgi?id=2058803
Previously we've only suggested adding `Copy` bounds when the type being
moved/copied is a type parameter (generic). With this commit we also
suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type
params
i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest
anything for `Option<String>`.
Future work: it would be nice to also suggest adding `.clone()` calls
Rollup of 3 pull requests
Successful merges:
- #94359 (Fix inconsistent symbol mangling of integers constants with -Zverbose)
- #94465 (6 - Make more use of `let_chains`)
- #94470 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix inconsistent symbol mangling of integers constants with -Zverbose
The `PrettyPrinter` changes formatting of array size and integer
constants based on `-Zverbose`, so its implementation cannot be used in
legacy symbol mangling.
Example symbol demangling before changes:
```console
$ cat a.rs
pub struct A<T>(T);
impl A<[u8; 128]> { pub fn f() {} }
$ rustc --crate-type=lib a.rs -Zverbose=n && nm -C ./liba.rlib
00000000 T a::A<[u8; 128]>::f
$ rustc --crate-type=lib a.rs -Zverbose=y && nm -C ./liba.rlib
00000000 T a::A<[u8; Const { ty. usize, val. Value(Scalar(0x0000000000000080)) }]>::f
```
Add `rustc_middle::ty::suggest_constraining_type_params` that suggests
adding multiple constraints.
`suggest_constraining_type_param` now just forwards params to this new
function.
Check method input expressions once
If the user mistakenly forgets to wrap their method args in a tuple, then the compiler tries to check that types within the tuple match the expression args. This means we call `check_expr` once within this diagnostic code, so when we check the expr once again in `demand_compatible`, we attempt to apply expr adjustments twice, leading to ICEs.
This PR attempts to fix this by skipping the expression type check in `demand_compatible` if we have detected an method arg mismatch at all.
This does lead to a single UI test regressing slightly, due to a diagnostic disappearing, though I don't know if it is generally meaningful to even raise an type error after noting that the argument count is incorrect in a function call, since the user might be providing (in-context) meaningless expressions to the wrong method.
I can adjust this to be a bit more targeted (to just skip checking exprs in `demand_compatible` in the tuple case) if this UI test regression is a problem.
fixes#94334
cc #94291
Also drive-by fixup of `.node_type(expr.hir_id)` to `.expr_ty(expr)`, since that method exists.
Lint against more useless `#[must_use]` attributes
This expands the existing `#[must_use]` check in `unused_attributes` to lint against pretty much everything `#[must_use]` doesn't support.
Fixes#93906.
Generalize "remove `&`" and "add `*`" suggestions to more than one deref
Suggest removing more than one `&` and `&mut`, along with suggesting adding more than one `*` (or a combination of the two).
r? `@estebank`
(since you're experienced with these types of suggestions, feel free to reassign)
If they are trying to use features rustc doesn't yet know about,
request a feature request.
Additionally, also warn against using feature names without leading `+`
or `-` signs.
Caching the stable hash of Ty within itself
Instead of computing stable hashes on types as needed, we compute it during interning.
This way we can, when a hash is requested, just hash that hash, which is significantly faster than traversing the type itself.
We only do this for incremental for now, as incremental is the only frequent user of stable hashing.
As a next step we can try out
* moving the hash and TypeFlags to Interner, so projections and regions get the same benefit (tho regions are not nested, so maybe that's not a good idea? Would be nice for dedup tho)
* start comparing types via their stable hash instead of their address?
The `PrettyPrinter` changes formatting of array size and integer
constants based on `-Zverbose`, so its implementation cannot be used in
legacy symbol mangling.
Fix ICE when passing block to while-loop condition
We were incorrectly delaying a bug when we passed _any_ block (that evaluated to `()`) to a while loop. This PR makes the check a bit more sophisticated.
We should only suppress the error here in cases that are equivalent to those we find in #93574 (i.e. only while loop conditions that have destructuring assignment expressions in them).
Fixes#93997
cc `@estebank` who added this code
I would not be opposed to removing the delay-bug altogether, and just emitting this error always. I much prefer duplicate errors over no errors.
* Recover from invalid `'label: ` before block.
* Make suggestion to enclose statements in a block multipart.
* Point at `match`, `while`, `loop` and `unsafe` keywords when failing
to parse their expression.
* Do not suggest `{ ; }`.
* Do not suggest `|` when very unlikely to be what was wanted (in `let`
statements).
Only create a single expansion for each inline integration.
The inlining integrator used to create one expansion for each span from the callee body.
This PR reverses the logic to create a single expansion for the whole call,
which is more consistent with how macro expansions work for macros.
This should remove the large memory regression in #91743.
Apply noundef metadata to loads of types that do not permit raw init
This matches the noundef attributes we apply on arguments/return types.
Fixes (partially) #74378.
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function,
and then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can simply remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
Rollup of 7 pull requests
Successful merges:
- #94396 (1 - Make more use of `let_chains`)
- #94397 (Document that pre-expansion lint passes are softly deprecated)
- #94399 (Add test for #79465 to prevent regression)
- #94409 (avoid rebuilding bootstrap when PATH changes)
- #94415 (Use the first codegen backend in the config.toml as default)
- #94417 (Fix duplicated impl links)
- #94420 (3 - Make more use of `let_chains`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Apply noundef attribute to all scalar types which do not permit raw init
Beyond `&`/`&mut`/`Box`, this covers `char`, enum discriminants, `NonZero*`, etc.
All such types currently cause a Miri error if left uninitialized,
and an `invalid_value` lint in cases like `mem::uninitialized::<char>()`.
Note that this _does not_ change whether or not it is UB for `u64` (or
other integer types with no invalid values) to be undef.
Fixes (partially) #74378.
r? `@ghost` (blocked on #94127)
`@rustbot` label S-blocked
Use the first codegen backend in the config.toml as default
It is currently hard coded to llvm if enabled and cranelift otherwise.
This made some sense when cranelift was the only alternative codegen
backend. Since the introduction of the gcc backend this doesn't make
much sense anymore. Before this PR bootstrapping rustc using a backend
other than llvm or cranelift required changing the source of
rustc_interface. With this PR it becomes a matter of putting the right
backend as first enabled backend in config.toml.
cc ```@antoyo```
Document that pre-expansion lint passes are softly deprecated
The pre-expansion lint pass has been softly deprecated since https://github.com/rust-lang/rust/pull/69838. Every once in a while I see someone mention it as a possibility, only get the feedback that it's deprecated. This PR officially documents that the method is soft deprecated to have a single point of truth for it.
That's it. Have a great rest of the day 🙃
---
* See [rust#69838](https://github.com/rust-lang/rust/pull/69838)
* See [rust-clippy#5518](https://github.com/rust-lang/rust-clippy/pull/5518)
LLVM really dislikes this and will assert, saying something along the
lines of:
```
rustc: llvm/lib/MC/MCSubtargetInfo.cpp:60: void ApplyFeatureFlag(
llvm::FeatureBitset&, llvm::StringRef, llvm::ArrayRef<llvm::SubtargetFeatureKV>
): Assertion
`SubtargetFeatures::hasFlag(Feature) && "Feature flags should start with '+' or '-'"`
failed.
```
This expands the existing `#[must_use]` check in `unused_attributes`
to lint against pretty much everything `#[must_use]` doesn't support.
Fixes#93906.
Avoid query cache sharding code in single-threaded mode
In non-parallel compilers, this is just adding needless overhead at compilation time (since there is only one shard statically anyway). This amounts to roughly ~10 seconds reduction in bootstrap time, with overall neutral (some wins, some losses) performance results.
Parallel compiler performance should be largely unaffected by this PR; sharding is kept there.
It is currently hard coded to llvm if enabled and cranelift otherwise.
This made some sense when cranelift was the only alternative codegen
backend. Since the introduction of the gcc backend this doesn't make
much sense anymore. Before this PR bootstrapping rustc using a backend
other than llvm or cranelift required changing the source of
rustc_interface. With this PR it becomes a matter of putting the right
backend as first enabled backend in config.toml.
rustc_trait_selection: adopt let else in more places
Continuation of #89933, #91018, #91481, #93046, #93590, #94011.
I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This PR handles rustc_trait_selection.
No branch protection metadata unless enabled
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.
This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.
Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
Beyond `&`/`&mut`/`Box`, this covers `char`, discriminants, `NonZero*`, etc.
All such types currently cause a Miri error if left uninitialized,
and an `invalid_value` lint in cases like `mem::uninitialized::<char>()`
Note that this _does not_ change whether or not it is UB for `u64` (or
other integer types with no invalid values) to be undef.
Restrict query recursion in `needs_significant_drop`
Overly aggressive use of the query system to improve caching lead to query cycles and consequently ICEs. This patch fixes this by restricting the use of the query system as a cache to those cases where it is definitely correct.
Closes#92725 .
This is essentially a revert of #90845 for the significant drop case only. The general `needs_drop` still does the same thing. The hope is that this is enough to preserve the performance improvements of that PR while fixing the ICE. Should get a perf run to verify that this is the case.
cc `@cjgillot`
Initiate the inner usage of `let_chains`
The intention here is create a strong and robust foundation for a possible future stabilization so please, do not let the lack of any external tool support prevent the merge of this PR. Besides, `let_chains` is useful by itself.
cc #53667
Rollup of 5 pull requests
Successful merges:
- #93400 (Do not suggest using a const parameter when there are bounds on an unused type parameter)
- #93982 (Provide extra note if synthetic type args are specified)
- #94087 (Remove unused `unsound_ignore_borrow_on_drop`)
- #94235 (chalk: Fix wrong debrujin index in opaque type handling.)
- #94306 (Avoid exhausting stack space in dominator compression)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid exhausting stack space in dominator compression
Doesn't add a test case -- I ended up running into this while playing with the generated example from #43578, which we could do with a run-make test (to avoid checking a large code snippet into tree), but I suspect we don't want to wait for it to compile (locally it takes ~14s -- not terrible, but doesn't seem worth it to me). In practice stack space exhaustion is difficult to test for, too, since if we set the bound too low a different call structure above us (e.g., a nearer ensure_sufficient_stack call) would let the test pass even with the old impl, most likely.
Locally it seems like this manages to perform approximately equivalently to the recursion, but will run perf to confirm.
chalk: Fix wrong debrujin index in opaque type handling.
A folder in opaque type lowering was substituting all opaque type references with a variable with debrujin index 0 ignoring how many binders deep we are.
This caused an ICE with `Not enough bound vars: ^0 not found in []` ([full logs](https://gist.github.com/Dirbaio/2b9374ff4fce37afb9d665dc9f0000df)) with the following code.
```rust
fn main() -> () {}
async fn foo(x: u32) -> u32 {
x
}
```
With the fix, it no longer ICEs. It still doesn't typecheck due to generator issues. I've added a "known-bug" test so that at least it doesn't regress back to ICEing.
r? ``@jackh726``
fix a message
implement a rustfix-applicable suggestion
implement `suggest_floating_point_literal`
add `ObligationCauseCode::BinOp`
remove duplicate code
fix function names in uitests
use `Diagnostic` instead of `DiagnosticBuilder`
Populate liveness facts when calling `get_body_with_borrowck_facts` without `-Z polonius`
For a new feature of [Flowistry](https://github.com/willcrichton/flowistry), a static-analysis tool, we need to obtain a `mir::Body`'s liveness facts using `get_body_with_borrowck_facts` (added in #86977). We'd like to do this without passing `-Z polonius` as a compiler arg to avoid borrow checking the entire crate.
Support for doing this was added in #88983, but the Polonius input facts used for liveness analysis are empty. This happens because the liveness input facts are populated in `liveness::generate` depending only on the value of `AllFacts::enabled` (which is toggled via compiler args).
This PR propagates the [`use_polonius`](8b09ba6a5d/compiler/rustc_borrowck/src/nll.rs (L168)) flag to `liveness::generate` to support populating liveness facts without requiring the `-Z polonius` flag.
This fix is somewhat patchy - if it'd be better to add more widely-accessible state (like `AllFacts::enabled`) I'd be open to ideas!
Rollup of 4 pull requests
Successful merges:
- #93850 (Don't ICE when an extern static is too big for the current architecture)
- #94154 (Wire up unstable rustc --check-cfg to rustdoc)
- #94353 (Fix debug_assert in unused lint pass)
- #94366 (Add missing item to release notes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix debug_assert in unused lint pass
This fixes a debug assertion in the unused lint pass. As a side effect, this also improves the span generated for tuples in the `unused_must_use` lint.
found in #94329
A reproducer for this would be
```rust
fn main() { (1, (3,)); }
```
Not sure, if I should add a regression test for a `debug_assert`.
Don't ICE when an extern static is too big for the current architecture
Fixes#93760
Emit an error instead of ICEing when an `extern` static's size overflows the allowed maximum for the target.
Changes the error message in the existing `delay_span_bug` call to the true layout error, first for debugging purposes, but opted to leave in to potentially assist future developers as it was being reached in unexpected ways already.
Print `ParamTy` and `ParamConst` instead of displaying them
Display for `ParamTy` and `ParamConst` is implemented in terms of print.
Using print avoids creating a new `FmtPrinter` just to display the
parameter name.
r? `@Mark-Simulacrum`
Miri fn ptr check: don't use conservative null check
In https://github.com/rust-lang/rust/pull/94270 I used the wrong NULL check for function pointers: `memory.ptr_may_be_null` is conservative even on machines that support ptr-to-int casts, leading to false errors in Miri.
This fixes that problem, and also replaces that foot-fun of a method with `scalar_may_be_null` which is never unnecessarily conservative.
r? `@oli-obk`
Remove an unnecessary restriction in `dest_prop`
I had asked about this [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Do.20unions.20have.20active.20fields.3F) but didn't receive a response, so putting up this PR that makes the change I think we can. If it turns out that this is wrong, hopefully I'll find out here. Reposting my Zulip comment:
> Not sure what channel to put this into, so using this as a fallback. The dest prop MIR opt has this comment:
>
> ```rust
> //! Subtle case: If `dest` is a, or projects through a union, then we have to make sure that there
> //! remains an assignment to it, since that sets the "active field" of the union. But if `src` is
> //! a ZST, it might not be initialized, so there might not be any use of it before the assignment,
> //! and performing the optimization would simply delete the assignment, leaving `dest`
> //! uninitialized.
> ```
>
> In particular, the claim seems to be that we can't take
> ```
> x = ();
> y.field = x;
> ```
> where `y` is a union having `field: ()` as one of its variants, and optimize the entire thing away (assuming `x` is unused otherwise). As far as I know though, Rust unions don't have active fields. Is this comment correct and am I missing something? Is there a worry about this interacting poorly with FFI code/C unions/LTO or something?
This PR just removes that comment and the associated code. Also it fixes one unrelated comment that did not match the code it was commenting on.
r? rust-lang/mir-opt
don't special case `DefKind::Ctor` in encoding
considering that we still use `DefKind::Ctor` for these in `Res`, this seems weird and definitely felt like a bug when encountering it while working on #89862.
r? `@cjgillot`
Remove in band lifetimes
As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety.
Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first.
r? `@scottmcm` (or feel free to reassign, just saw your last comment on #44524)
Closes#44524
This fixes a debug assertion in the unused lint pass. As a side effect,
this also improves the span generated for tuples in the
`unused_must_use` lint.
debuginfo: Simplify TypeMap used during LLVM debuginfo generation.
This PR simplifies the TypeMap that is used in `rustc_codegen_llvm::debuginfo::metadata`. It was unnecessarily complicated because it was originally implemented when types were not yet normalized before codegen. So it did it's own normalization and kept track of multiple unnormalized types being mapped to a single unique id.
This PR is based on https://github.com/rust-lang/rust/pull/93503, which is not merged yet.
The PR also removes the arena used for allocating string ids and instead uses `InlinableString` from the [inlinable_string](https://crates.io/crates/inlinable_string) crate. That might not be the best choice, since that crate does not seem to be very actively maintained. The [flexible-string](https://crates.io/crates/flexible-string) crate would be an alternative.
r? `@ghost`
Consider mutations as borrows in generator drop tracking
This is needed to match MIR more conservative approximation of any borrowed value being live across a suspend point (See #94067). This change considers an expression such as `x.y = z` to be a borrow of `x` and therefore keeps `x` live across suspend points.
r? `@nikomatsakis`
Use undef for (some) partially-uninit constants
There needs to be some limit to avoid perf regressions on large arrays
with undef in each element (see comment in the code).
Fixes: #84565
Original PR: #83698
Depends on LLVM 14: #93577
Convert `newtype_index` to a proc macro
The `macro_rules!` implementation was becomng excessively complicated,
and difficult to modify. The new proc macro implementation should make
it much easier to add new features (e.g. skipping certain `#[derive]`s)
rustc_errors: let `DiagnosticBuilder::emit` return a "guarantee of emission".
That is, `DiagnosticBuilder` is now generic over the return type of `.emit()`, so we'll now have:
* `DiagnosticBuilder<ErrorReported>` for error (incl. fatal/bug) diagnostics
* can only be created via a `const L: Level`-generic constructor, that limits allowed variants via a `where` clause, so not even `rustc_errors` can accidentally bypass this limitation
* asserts `diagnostic.is_error()` on emission, just in case the construction restriction was bypassed (e.g. by replacing the whole `Diagnostic` inside `DiagnosticBuilder`)
* `.emit()` returns `ErrorReported`, as a "proof" token that `.emit()` was called
(though note that this isn't a real guarantee until after completing the work on
#69426)
* `DiagnosticBuilder<()>` for everything else (warnings, notes, etc.)
* can also be obtained from other `DiagnosticBuilder`s by calling `.forget_guarantee()`
This PR is a companion to other ongoing work, namely:
* #69426
and it's ongoing implementation:
#93222
the API changes in this PR are needed to get statically-checked "only errors produce `ErrorReported` from `.emit()`", but doesn't itself provide any really strong guarantees without those other `ErrorReported` changes
* #93244
would make the choices of API changes (esp. naming) in this PR fit better overall
In order to be able to let `.emit()` return anything trustable, several changes had to be made:
* `Diagnostic`'s `level` field is now private to `rustc_errors`, to disallow arbitrary "downgrade"s from "some kind of error" to "warning" (or anything else that doesn't cause compilation to fail)
* it's still possible to replace the whole `Diagnostic` inside the `DiagnosticBuilder`, sadly, that's harder to fix, but it's unlikely enough that we can paper over it with asserts on `.emit()`
* `.cancel()` now consumes `DiagnosticBuilder`, preventing `.emit()` calls on a cancelled diagnostic
* it's also now done internally, through `DiagnosticBuilder`-private state, instead of having a `Level::Cancelled` variant that can be read (or worse, written) by the user
* this removes a hazard of calling `.cancel()` on an error then continuing to attach details to it, and even expect to be able to `.emit()` it
* warnings were switched to *only* `can_emit_warnings` on emission (instead of pre-cancelling early)
* `struct_dummy` was removed (as it relied on a pre-`Cancelled` `Diagnostic`)
* since `.emit()` doesn't consume the `DiagnosticBuilder` <sub>(I tried and gave up, it's much more work than this PR)</sub>,
we have to make `.emit()` idempotent wrt the guarantees it returns
* thankfully, `err.emit(); err.emit();` can return `ErrorReported` both times, as the second `.emit()` call has no side-effects *only* because the first one did do the appropriate emission
* `&mut Diagnostic` is now used in a lot of function signatures, which used to take `&mut DiagnosticBuilder` (in the interest of not having to make those functions generic)
* the APIs were already mostly identical, allowing for low-effort porting to this new setup
* only some of the suggestion methods needed some rework, to have the extra `DiagnosticBuilder` functionality on the `Diagnostic` methods themselves (that change is also present in #93259)
* `.emit()`/`.cancel()` aren't available, but IMO calling them from an "error decorator/annotator" function isn't a good practice, and can lead to strange behavior (from the caller's perspective)
* `.downgrade_to_delayed_bug()` was added, letting you convert any `.is_error()` diagnostic into a `delay_span_bug` one (which works because in both cases the guarantees available are the same)
This PR should ideally be reviewed commit-by-commit, since there is a lot of fallout in each.
r? `@estebank` cc `@Manishearth` `@nikomatsakis` `@mark-i-m`
As an example:
#[test]
#[ignore = "not yet implemented"]
fn test_ignored() {
...
}
Will now render as:
running 2 tests
test tests::test_ignored ... ignored, not yet implemented
test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s
These links never worked, but the lint was suppressed due to the fact
that the span was pointing into the macro. With the new macro
implementation, the span now points directly to the doc comment in the
macro invocation, so it's no longer suppressed.
The `macro_rules!` implementation was becomng excessively complicated,
and difficult to modify. The new proc macro implementation should make
it much easier to add new features (e.g. skipping certain `#[derive]`s)
Avoid emitting full macro body into JSON errors
While investigating https://github.com/rust-lang/rust/issues/94322, it was noted that currently the JSON diagnostics for macro backtraces include the full def_site span -- the whole macro body.
It seems like this shouldn't be necessary, so this PR adjusts the span to just be the "guessed head", typically the macro name. It doesn't look like we keep enough information to synthesize a nicer span here at this time.
Atop #92123, this reduces output for the src/test/ui/suggestions/missing-lifetime-specifier.rs test from 660 KB to 156 KB locally.
properly handle fat pointers to uninhabitable types
Calculate the pointee metadata size by using `tcx.struct_tail_erasing_lifetimes` instead of duplicating the logic in `fat_pointer_kind`. Open to alternatively suggestions on how to fix this.
Fixes#94149
r? ````@michaelwoerister```` since you touched this code last, I think!
Improve `--check-cfg` implementation
This pull-request is a mix of improvements regarding the `--check-cfg` implementation:
- Simpler internal representation (usage of `Option` instead of separate bool)
- Add --check-cfg to the unstable book (based on the RFC)
- Improved diagnostics:
* List possible values when the value is unexpected
* Suggest if possible a name or value that is similar
- Add more tests (well known names, mix of combinations, ...)
r? ```@petrochenkov```
better ObligationCause for normalization errors in `can_type_implement_copy`
Some logic is needed so we can point to the field when given totally nonsense types like `struct Foo(<u32 as Iterator>::Item);`
Fixes#93687
Overly aggressive use of the query system to improve caching lead to query cycles and consequently
ICEs. This patch fixes this by restricting the use of the query system as a cache to those cases
where it is definitely correct.
