It's a macro that just creates an enum with a `from_u32` method. It has
two arms. One is unused and the other has a single use.
This commit inlines that single use and removes the whole macro. This
increases readability because we don't have two different macros
interacting (`enum_from_u32` and `language_item_table`).
It provides a way to effectively embed a linked list within an
`IndexVec` and also iterate over that list. It's written in a very
generic way, involving two traits `Links` and `LinkElem`. But the
`Links` trait is only impl'd for `IndexVec` and `&IndexVec`, and the
whole thing is only used in one module within `rustc_borrowck`. So I
think it's over-engineered and hard to read. Plus it has no comments.
This commit removes it, and adds a (non-generic) local iterator for the
use within `rustc_borrowck`. Much simpler.
It is optimized for lists with a single element, avoiding the need for
an allocation in that case. But `SmallVec<[T; 1]>` also avoids the
allocation, and is better in general: more standard, log2 number of
allocations if the list exceeds one item, and a much more capable API.
This commit removes `TinyList` and converts the two uses to
`SmallVec<[T; 1]>`. It also reorders the `use` items in the relevant
file so they are in just two sections (`pub` and non-`pub`), ordered
alphabetically, instead of many sections. (This is a relevant part of
the change because I had to decide where to add a `use` item for
`SmallVec`.)
And move the `repr` line after the `derive` line, where it's harder to
overlook. (I overlooked it initially, and didn't understand how this
type worked.)
Simplify `use crate::rustc_foo::bar` occurrences.
They can just be written as `use rustc_foo::bar`, which is far more standard. (I didn't even know that a `crate::` prefix was valid.)
r? ``@eholk``
Remove braces when fixing a nested use tree into a single item
[Back in 2019](https://github.com/rust-lang/rust/pull/56645) I added rustfix support for the `unused_imports` lint, to automatically remove them when running `cargo fix`. For the most part this worked great, but when removing all but one childs of a nested use tree it turned `use foo::{Unused, Used}` into `use foo::{Used}`. This is slightly annoying, because it then requires you to run `rustfmt` to get `use foo::Used`.
This PR automatically removes braces and the surrouding whitespace when all but one child of a nested use tree are unused. To get it done I had to add the span of the nested use tree to the AST, and refactor a bit the code I wrote back then.
A thing I noticed is, there doesn't seem to be any `//@ run-rustfix` test for fixing the `unused_imports` lint. I created a test in `tests/suggestions` (is that the right directory?) that for now tests just what I added in the PR. I can followup in a separate PR to add more tests for fixing `unused_lints`.
This PR is best reviewed commit-by-commit.
Previously, `break` inside `gen` blocks and functions
were incorrectly identified to be enclosed by a closure.
This PR fixes it by displaying an appropriate error message
for async blocks, async closures, async functions, gen blocks,
gen closures, gen functions, async gen blocks, async gen closures
and async gen functions.
Note: gen closure and async gen closure are not supported by the
compiler yet but I have added an error message here assuming that
they might be implemented in the future.
Also, fixes grammar in a few places by replacing
`inside of a $coroutine` with `inside a $coroutine`.
Fix insufficient logic when searching for the underlying allocation
This PR fixes the logic inside the `invalid_reference_casting` lint, when trying to lint on bigger memory layout casts.
More specifically when looking for the "underlying allocation" we were wrongly assuming that when we got `&mut slice[index]` that `slice[index]` was the allocation, but it's not.
Fixes https://github.com/rust-lang/rust/issues/124685
Handle normalization failure in `struct_tail_erasing_lifetimes`
Fixes#113272
The ICE occurred because the struct being normalized had an error. This PR adds some defensive code to guard against that.
rustc: Some small changes for the wasm32-wasip2 target
This commit has a few changes for the wasm32-wasip2 target. The first two are aimed at improving the compatibility of using `clang` as an external linker driver on this target. The default target to LLVM is updated to match the Rust target and additionally the `-fuse-ld=lld` argument is dropped since that otherwise interferes with clang's own linker detection. The only linker on wasm targets is LLD but on the wasip2 target a wrapper around LLD, `wasm-component-ld`, is used to drive the process and perform steps necessary for componentization.
The final commit changes the output of all objects on the wasip2 target to being PIC by default. This improves compatibilty with shared libaries but notably does not mean that there's a turnkey solution for shared libraries. The hope is that by having the standard libray work both with and without dynamic libraries will make experimentation easier.
Improve `rustc_parse::Parser`'s debuggability
The main event is the final commit where I add `Parser::debug_lookahead`. Everything else was basically cleaning up things that bugged me (debugging, as it were) until I felt comfortable enough to actually work on it.
The motivation is that it's annoying as hell to try to figure out how the debug infra works in rustc without having basic queries like `debug!(?parser);` come up "empty". However, Parser has a lot of fields that are mostly irrelevant for most debugging, like the entire ParseSess. I think `Parser::debug_lookahead` with a capped lookahead might be fine as a general-purpose Debug impl, but this adapter version was suggested to allow more choice, and admittedly, it's a refined version of what I was already handrolling just to get some insight going.
I tried debugging a parser-related issue but found it annoying to not be
able to easily peek into the Parser's token stream.
Add a convenience fn that offers an opinionated view into the parser,
but one that is useful for answering basic questions about parser state.
coverage: Branch coverage support for let-else and if-let
This PR adds branch coverage instrumentation for let-else and if-let, including let-chains.
This lifts two of the limitations listed at #124118.
This commit changes the new `wasm32-wasip2` target to being PIC by
default rather than the previous non-PIC by default. This change is
intended to make it easier for the standard library to be used in a
shared object in its precompiled form. This comes with a hypothetical
modest slowdown but it's expected that this is quite minor in most use
cases or otherwise wasm compilers and/or optimizing runtimes can elide
the cost.
Do not ICE on `AnonConst`s in `diagnostic_hir_wf_check`
Fixes#122989
Below is the snippet from #122989 that ICEs:
```rust
trait Traitor<const N: N<2> = 1, const N: N<2> = N> {
fn N(&N) -> N<2> {
M
}
}
trait N<const N: Traitor<2> = 12> {}
```
The `AnonConst` that triggers the ICE is the `2` in the param `const N: N<2> = 1`. The currently existing code in `diagnostic_hir_wf_check` deals only with `AnonConst`s that are default values of some param, but the `2` is not a default value. It is just an `AnonConst` HIR node inside a `TraitRef` HIR node corresponding to `N<2>`. Therefore the existing code cannot handle it and this PR ensures that it does.
Rollup of 5 pull requests
Successful merges:
- #124738 (rustdoc: dedup search form HTML)
- #124827 (generalize hr alias: avoid unconstrainable infer vars)
- #124832 (narrow down visibilities in `rustc_parse::lexer`)
- #124842 (replace another Option<Span> by DUMMY_SP)
- #124846 (Don't ICE when we cannot eval a const to a valtree in the new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE when we cannot eval a const to a valtree in the new solver
Use `const_eval_resolve` instead of `try_const_eval_resolve` because naming aside, the former doesn't ICE when a value can't be evaluated to a valtree.
r? lcnr
never patterns: lower never patterns to `Unreachable` in MIR
This lowers a `!` pattern to "goto Unreachable". Ideally I'd like to read from the place to make it clear that the UB is coming from an invalid value, but that's tricky so I'm leaving it for later.
r? `@compiler-errors` how do you feel about a lil bit of MIR lowering
Adjust 64-bit ARM data layouts for LLVM update
LLVM has updated data layouts to specify `Fn32` on 64-bit ARM to avoid C++ accidentally underaligning functions when trying to comply with member function ABIs.
This should only affect Rust in cases where we had a similar bug (I don't believe we have one), but our data layout must match to generate code.
As a compatibility adaptatation, if LLVM is not version 19 yet, `Fn32` gets voided from the data layout.
See llvm/llvm-project#90415
`@rustbot` label: +llvm-main
cc `@krasimirgg`
r? `@durin42`
borrowck: prepopulate opaque storage more eagerly
otherwise we ICE due to ambiguity when normalizing while computing implied bounds.
r? ``@compiler-errors``
Record impl args in the proof tree in new solver
Rather than rematching them during select.
Also use `ImplSource::Param` instead of `ImplSource::Builtin` for alias-bound candidates, so we don't ICE in `Instance::resolve`.
r? lcnr
LLVM has updated data layouts to specify `Fn32` on 64-bit ARM to avoid
C++ accidentally underaligning functions when trying to comply with
member function ABIs.
This should only affect Rust in cases where we had a similar bug (I
don't believe we have one), but our data layout must match to generate
code.
As a compatibility adaptatation, if LLVM is not version 19 yet, `Fn32`
gets voided from the data layout.
See llvm/llvm-project#90415
Don't consider candidates with no failing where clauses when refining obligation causes in new solver
Improves error messages when we have param-env candidates that don't deeply unify (i.e. after alias-bounds).
r? lcnr
Prefer lower vtable candidates in select in new solver
Also, adjust the select visitor to only winnow when the *parent* goal is `Certainty::Yes`. This means that we won't winnow in cases when we have any ambiguous inference guidance from two candidates.
r? lcnr
Improve check-cfg CLI errors with more structured diagnostics
This PR improve check-cfg CLI errors with more structured diagnostics.
In particular it now shows the statement where the error occurred, what kind lit it is, as well as pointing users to the doc for more details.
`@rustbot` label +F-check-cfg
Rollup of 3 pull requests
Successful merges:
- #124742 (Add `rustfmt` cfg to well known cfgs list)
- #124765 ([rustdoc] Fix bad color for setting cog in ayu theme)
- #124768 ([resubmission] Meta: Enable the brand new triagebot transfer command)
r? `@ghost`
`@rustbot` modify labels: rollup
Move some tests from `rustc_expand` to `rustc_parse`.
There are some test cases involving `parse` and `tokenstream` and `mut_visit` that are located in `rustc_expand`. Because it used to be the case that constructing a `ParseSess` required the involvement of `rustc_expand`. However, since #64197 merged (a long time ago) `rust_expand` no longer needs to be involved.
This commit moves the tests into `rustc_parse`. This is the optimal place for the `parse` tests. It's not ideal for the `tokenstream` and `mut_visit` tests -- they would be better in `rustc_ast` -- but they still rely on parsing, which is not available in `rustc_ast`. But `rustc_parse` is lower down in the crate graph and closer to `rustc_ast` than `rust_expand`, so it's still an improvement for them.
The exact renaming is as follows:
- rustc_expand/src/mut_visit/tests.rs -> rustc_parse/src/parser/mut_visit/tests.rs
- rustc_expand/src/tokenstream/tests.rs -> rustc_parse/src/parser/tokenstream/tests.rs
- rustc_expand/src/tests.rs + rustc_expand/src/parse/tests.rs -> compiler/rustc_parse/src/parser/tests.rs
The latter two test files are combined because there's no need for them to be separate, and having a `rustc_parse::parser::parse` module would be weird. This also means some `pub(crate)`s can be removed.
r? `@compiler-errors`
The code in `extract_mcdc_mappings` that allocates these bytes already knows
how many are needed in total, so there's no need to immediately recompute that
value in the calling function.
There are some test cases involving `parse` and `tokenstream` and
`mut_visit` that are located in `rustc_expand`. Because it used to be
the case that constructing a `ParseSess` required the involvement of
`rustc_expand`. However, since #64197 merged (a long time ago)
`rust_expand` no longer needs to be involved.
This commit moves the tests into `rustc_parse`. This is the optimal
place for the `parse` tests. It's not ideal for the `tokenstream` and
`mut_visit` tests -- they would be better in `rustc_ast` -- but they
still rely on parsing, which is not available in `rustc_ast`. But
`rustc_parse` is lower down in the crate graph and closer to `rustc_ast`
than `rust_expand`, so it's still an improvement for them.
The exact renaming is as follows:
- rustc_expand/src/mut_visit/tests.rs -> rustc_parse/src/parser/mut_visit/tests.rs
- rustc_expand/src/tokenstream/tests.rs -> rustc_parse/src/parser/tokenstream/tests.rs
- rustc_expand/src/tests.rs + rustc_expand/src/parse/tests.rs ->
compiler/rustc_parse/src/parser/tests.rs
The latter two test files are combined because there's no need for them
to be separate, and having a `rustc_parse::parser::parse` module would
be weird. This also means some `pub(crate)`s can be removed.
coverage: Split out MC/DC mappings from `BcbMappingKind`
These variants were added to `BcbMappingKind` as part of the [MC/DC coverage](https://en.wikipedia.org/wiki/Modified_Condition/Decision_Coverage) implementation in #123409, because that was the path-of-least-resistance for integrating them into the existing code.
However, they ultimately represent complex concepts that the enum was not intended to handle, leading to more complexity in the code that processes them. This PR therefore follows in the footsteps of #124545, and splits the MC/DC mappings out into their own dedicated vectors of structs.
After that, `BcbMappingKind` itself ends up having only one variant (`Code`), so this PR also flattens that enum into its enclosing struct, renamed to `mapping::CodeMapping`.
---
No functional changes.
This will conflict slightly with #124571, but hopefully that should be easy to resolve either way.
`@rustbot` label +A-code-coverage
Rollup of 6 pull requests
Successful merges:
- #124148 (rustdoc-search: search for references)
- #124668 (Fix bootstrap panic when build from tarball)
- #124736 (compiler: upgrade time from 0.3.34 to 0.3.36)
- #124748 (Fix unwinding on 32-bit watchOS ARM (v2))
- #124749 (Stabilize exclusive_range_pattern (v2))
- #124750 (Document That `f16` And `f128` Hardware Support is Limited (v2))
r? `@ghost`
`@rustbot` modify labels: rollup
compiler: upgrade time from 0.3.34 to 0.3.36
This ensures the version of `time` used in `rustc` includes this change: https://github.com/time-rs/time/pull/671.
This fix is a necessary prerequisite for #99969, which adds `FromIterator` implementations for `Box<str>`. Previously, `time` had an `Into::into` that resolved to the identity impl followed by a `collect::<Result<Box<_>, _>>()`. With the new FromIterator implementations for Box<str>, the Into::into resolution is ambiguous and time fails to compile. Thanks to `@dtolnay` for the analysis in https://github.com/rust-lang/rust/pull/99969#issuecomment-2001422230.
The `time` fix removes the identity `Into::into` conversion, allowing `time` to compile with the new `FromIterator` implementations. This version of `time` also matches what `cargo` recently switched to in https://github.com/rust-lang/cargo/pull/13834.
Remove suggestion about iteration count in coerce
Fixes#122561
The iteration count-centric suggestion was implemented in PR #100094, but it was based on the wrong assumption that the type mismatch error depends on the number of times the loop iterates. As it turns out, that is not true (see this comment for details: https://github.com/rust-lang/rust/pull/122679#issuecomment-2017432531)
This PR attempts to remedy the situation by changing the suggestion from the one centered on iteration count to a simple suggestion to add a return value.
It should also fix#100285 by simply making it redundant.
This ensures the version of time used in rustc includes this change:
https://github.com/time-rs/time/pull/671.
This fix is a necessary prerequisite for #99969,
which adds FromIterator implementations for Box<str>.
Previously, time had an Into::into that resolved to the identity impl
followed by a collect::<Result<Box<_>, _>>().
With the new FromIterator implementations for Box<str>,
the Into::into resolution is ambiguous and time fails to compile.
The fix removes the identity Into::into conversion,
allowing time to compile with the new FromIterator implementations.
This version of time also matches what cargo recently switched to
in https://github.com/rust-lang/cargo/pull/13834.
Stop `llvm.expect`ing assert terminators
We're putting `llvm.expect` calls before the <https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.TerminatorKind.html#variant.Assert> terminators.
But we don't need them. One of the arms is always to a panic function that's marked `#[cold]`, which is `cold` <https://llvm.org/docs/LangRef.html#function-attributes> in LLVM, which
> When computing edge weights, basic blocks post-dominated by a cold function call are also considered to be cold; and, thus, given low weight.
So even without us emitting the extra intrinsic call, LLVM knows what to expect for the `br`. Thus we can save the (small) effort of emitting it and then LLVM optimizing it out.
r? compiler
Implement `do_not_recommend` in the new solver
Put the test into `diagnostic_namespace` test folder even though it's not in the diagnostic namespace, because it should be soon.
r? lcnr
cc `@weiznich`
Update Cargo specific diagnostics in check-cfg
This PR updates the Cargo specific diagnostics for check-cfg/`unexpected_cfgs` lint.
Specifically it update to new url and use the double-column (instead of one) in the Cargo directive suggestion.
`@rustbot` label +F-check-cfg
cc `@weihanglo`
Only consider ambiguous goals when finding best obligation for ambiguities
We don't care about ambiguous goals when reporting true errors, and vice versa for ambiguities.
r? lcnr
interpret, miri: uniform treatments of intrinsics/functions with and without return block
A long time ago we didn't have a `dest: &MPlaceTy<'tcx, Self::Provenance>` for diverging functions, and since `dest` is used so often we special-cased these non-returning intrinsics and functions so that we'd have `dest` available everywhere else. But this has changed a while ago, now only the return block `ret` is optional, and there's a convenient `return_to_block` function for dealing with the `None` case.
So there no longer is any reason to treat diverging intrinsics/functions any different from those that do return.
Various improvements to entrypoint code
This moves some code around and adds some documentation comments to make it easier to understand what's going on with the entrypoint logic, which is a bit complicated.
The only change in behavior is consolidating the error messages for unix_sigpipe to make the code slightly simpler.
This moves some code around and adds some documentation comments to make
it easier to understand what's going on with the entrypoint logic, which
is a bit complicated.
The only change in behavior is consolidating the error messages for
unix_sigpipe to make the code slightly simpler.
Set non-leaf frame pointers on Fuchsia targets
This is part of our work to enable shadow call stack sanitization on Fuchsia, see [this Fuchsia issue](https://g-issues.fuchsia.dev/issues/327643884).
r? ``@tmandry``
Make `Bounds.clauses` private
Construct it through `Bounds::default()`, then consume the clauses via the method `Bounds::clauses()`.
This helps with effects desugaring where `clauses()` is not only the clauses within the `clauses` field.
Trim crate graph
This PR removes some unnecessary `Cargo.toml` entries, and makes some other small related cleanups that I found while looking at this stuff.
r? ```@pnkfelix```
Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.
So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.
Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
Use a proof tree visitor to refine the `Obligation` for error reporting in new solver
With the magic of `ProofTreeVisitor`, we can close the gap that we have on `ObligationCause`s being not as descriptive in the new trait solver.
r? lcnr
Needs some work and obviously documentation.
This argument isn't necessary for WebAssembly targets since `wasm-ld` is
the only linker for the targets. Passing it otherwise interferes with
Clang's linker selection on `wasm32-wasip2` so avoid it altogether.
Now that branch and MC/DC mappings have been split out into separate types and
vectors, this enum is no longer needed, since it only represents ordinary
"code" regions.
(We can revisit this decision if we ever add support for other region kinds,
such as skipped regions or expansion regions. But at that point, we might just
add new structs/vectors for those kinds as well.)
Some hir cleanups
It seemed odd to not put `AnonConst` in the arena, compared with the other types that we did put into an arena. This way we can also give it a `Span` without growing a lot of other HIR data structures because of the extra field.
r? compiler
This commit changes the LLVM target of for the Rust `wasm32-wasip2`
target to `wasm32-wasip2` as well. LLVM does a bit of detection on the
target string to know when to call `wasm-component-ld` vs `wasm-ld` so
otherwise clang is invoking the wrong linker.
Account for immutably borrowed locals in MIR copy-prop and GVN
For the most part, we consider that immutably borrowed `Freeze` locals still fulfill SSA conditions. As the borrow is immutable, any use of the local will have the value given by the single assignment, and there can be no surprise.
This allows copy-prop to merge a non-borrowed local with a borrowed local. We chose to keep copy-classes heads unborrowed, as those may be easier to optimize in later passes.
This also allows to GVN the value behind an immutable borrow. If a SSA local is borrowed, dereferencing that borrow is equivalent to copying the local's value: re-executing the assignment between the borrow and the dereference would be UB.
r? `@ghost` for perf
coverage: Clean up creation of MC/DC condition bitmaps
This PR improves the code for creating and initializing [MC/DC](https://en.wikipedia.org/wiki/Modified_condition/decision_coverage) condition bitmap variables, as introduced by #123409 and modified by #124255.
- The condition bitmap variables are now created eagerly at the start of per-function codegen, via a new `init_coverage` method in `CoverageInfoBuilderMethods`. This avoids having to retroactively create the bitmaps while doing codegen for an individual coverage statement.
- As a result, we can now create and initialize those bitmaps using existing safe APIs, instead of having to perform our own unsafe call to `llvm::LLVMBuildAlloca`.
- This PR also tweaks the way we count the number of condition bitmaps needed, by tracking the total number of bitmaps needed (max depth + 1), instead of only tracking the maximum depth. This reduces the potential for subtle off-by-one confusion.
Stabilize the size of incr comp object file names
The current implementation does not produce stable-length paths, and we create the paths in a way that makes our allocation behavior is nondeterministic. I think `@eddyb` fixed a number of other cases like this in the past, and this PR fixes another one. Whether that actually matters I have no idea, but we still have bimodal behavior in rustc-perf and the non-uniformity in `find` and `ls` was bothering me.
I've also removed the truncation of the mangled CGU names. Before this PR incr comp paths look like this:
```
target/debug/incremental/scratch-38izrrq90cex7/s-gux6gz0ow8-1ph76gg-ewe1xj434l26w9up5bedsojpd/261xgo1oqnd90ry5.o
```
And after, they look like this:
```
target/debug/incremental/scratch-035omutqbfkbw/s-gux6borni0-16r3v1j-6n64tmwqzchtgqzwwim5amuga/55v2re42sztc8je9bva6g8ft3.o
```
On the one hand, I'm sure this will break some people's builds because they're on Windows and only a few bytes from the path length limit. But if we're that seriously worried about the length of our file names, I have some other ideas on how to make them smaller. And last time I deleted some hash truncations from the compiler, there was a huge drop in the number if incremental compilation ICEs that were reported: https://github.com/rust-lang/rust/pull/110367https://github.com/rust-lang/rust/pull/110367
---
Upon further reading, this PR actually fixes a bug. This comment says the CGU names are supposed to be a fixed-length hash, and before this PR they aren't: ca7d34efa9/compiler/rustc_monomorphize/src/partitioning.rs (L445-L448)
Generalize `adjust_from_tcx` for `Allocation`
Previously, `adjust_from_tcx` would take an `Allocation` and "adjust allocation from the ones in `tcx` to a custom Machine instance [...]".
This PR generalizes this so the Machine instance can also determine the `Bytes` type of the output `Allocation`.
r? `@RalfJung`
There are a few common abbreviations like `use rustc_ast as ast` and
`use rust_hir as hir` for names that are used a lot. But there are also
some cases where a crate is renamed just once in the whole codebase, and
that ends up making things harder to read rather than easier. This
commit removes them.
It is currently an enum and the `tts` and `idx` fields are repeated
across the two variants.
This commit splits it into a struct `Frame` and an enum `FrameKind`, to
factor out the duplication. The commit also renames `Frame::new` as
`Frame::new_delimited` and adds `Frame::new_sequence`. I.e. both
variants now have a constructor.
Control flow never gets past the end of the `ExpandResult::Retry` match
arm, due to the `span_bug` and the `continue`. Therefore, the code after
the match can only be reached from the `ExpandResult::Ready` arm.
This commit moves that code after the match into the
`ExpandResult::Ready` arm, avoiding the need for the `continue` in the
`ExpandResult::Retry` arm.
`ConstKind::Value` is the only variant where control flow leaves the
first match on `impl_ct.kind()`, so there is no need for a second match
on the same expression later on.
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`
I don't think there is any need for the function, given that we can just access the `.types`, similarly to all other primitives?
remove extraneous note on `UnableToRunDsymutil` diagnostic
If I understand [this FIXME](1367827eac/compiler/rustc_macros/src/diagnostics/diagnostic.rs (L205)) correctly, it seems we don't yet validate subdiagnostics, so `#[note]` and co in the `#[derive(Diagnostic]` item could be out-of-sync with the fluent message, without causing compile errors.
It was the case for `rustc_codegen_ssa::errors::UnableToRunDsymutil`, causing the ICE in #124392.
I've grepped and scripted my way through most of our diagnostics structs and fluent bundles and the above was the only such extraneous `#[note]`/`#[note(name)]`/`#[help]`/`#[warning]` I could find, so hopefully there aren't many others like it.
I haven't checked if the opposite can happen, a `.note = ` in a fluent message that is lacking a corresponding `#[note]` on the struct and not causing an error, but maybe it's possible?
r? ``@davidtwco``
fixes#124392
always print nice 'std not found' error when std is not found
Fixes https://github.com/rust-lang/miri/issues/3529
Arguably Miri is doing something odd by letting people create no-std sysroots for arbitrary targets -- but equally arguably, there's no good reason for rustc to special-case the host triple here. Being a non-host triple does not imply the target is a no-std target, after all.
Adjust `#[macro_export]`/doctest help suggestion for non_local_defs lint
This PR adjust the help suggestion of the `non_local_definitions` lint when encountering a `#[macro_export]` at top-level doctest.
So instead of a non-sentential help suggestion to move the `macro_rules!` up above the `rustdoc`-generated function. We now suggest users to declare their own function.
Fixes *(partially, needs backport)* #124534
Add a lint against never type fallback affecting unsafe code
~~I'm not very happy with the code quality... `VecGraph` not allowing you to get predecessors is very annoying. This should work though, so there is that.~~ (ended up updating `VecGraph` to support getting predecessors)
~~First few commits are from https://github.com/rust-lang/rust/pull/123934https://github.com/rust-lang/rust/pull/123980~~
This is a workaround for #122758, but it's not clear why 1.79 requires a
more extensive amount of no_inline than the previous release. Seems like
there's something relatively subtle happening here.
Rewrite select (in the new solver) to use a `ProofTreeVisitor`
We can use a proof tree visitor rather than collecting and recomputing all the nested goals ourselves.
Based on #124415
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful
**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:
> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.
I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?
The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.
Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.
r? lcnr or compiler
Because this now always takes place at the start of the function, we can just
use the normal `alloca` method and then initialize each bitmap immediately.
This patch also moves bitmap setup out of the `mcdc_parameters` method, because
there is no longer any particular reason for it to be there.
Lazily normalize inside trait ref during orphan check & consider ty params in rigid alias types to be uncovered
Fixes#99554, fixesrust-lang/types-team#104.
Fixes#114061.
Supersedes #100555.
Tracking issue for the future compatibility lint: #124559.
r? lcnr
Remove many `#[macro_use] extern crate foo` items
This requires the addition of more `use` items, which often make the code more verbose. But they also make the code easier to read, because `#[macro_use]` obscures where macros are defined.
r? `@fee1-dead`
Mention Both HRTB and Generic Lifetime Param in `E0637` documentation
The compiler (rustc 1.77.0) error for `and_without_explicit_lifetime()` in the erroneous code example suggests using a HRTB. But, the corrected example uses an explicit lifetime parameter.
This PR fixes it so that the documentation and the compiler suggestion for error code `E0637` are consistent with each other.
coverage: Split off `mappings.rs` from `spans.rs` and `from_mir.rs`
Originally, `spans.rs` was mainly concerned with extracting and post-processing spans from MIR, so that they could be used for block coverage instrumentation.
Over time it has organically expanded to include more responsibilities, especially relating to branch coverage and MC/DC coverage, that don't really fit its current name.
This PR therefore takes all the extra code that is *not* part of the old span-refinement engine, and moves it out into a new `mappings.rs` file.
---
No functional changes. I have deliberately avoided doing any follow-up (such as renaming types or functions), because this particular change is very rot-prone, and I want it to be as simple and self-contained as possible.
`@rustbot` label +A-code-coverage
because we are already marking unions `NoPropagation` in
`CanConstProp::check()`. That is enough to prevent any attempts
at const propagating unions and this second check is not needed.
Also improve a comment in `CanConstProp::check()`
Split mcdc code to a sub module of coverageinfo
A further work from #124217 . I have made relatively large changes when working on #124278 so that it would better split them from `coverageinfo.rs` to avoid potential troubling merge work with improved branch coverage by `@Zalathar` .
Besides `BlockMarkerGenerator` is added to avoid ownership problems (mostly needed for following change of #124278 )
All code changes are done in [a37d737a](a3d737a086) while the second commit just renames the file.
cc `@RenjiSann` `@Zalathar`
This will impact your current work.
and replace it with a simple note suggesting
returning a value.
The type mismatch error was never due to
how many times the loop iterates. It is more
because of the peculiar structure of what the for
loop desugars to. So the note talking about
iteration count didn't make sense
Rollup of 4 pull requests
Successful merges:
- #124519 (adapt a codegen test for llvm 19)
- #124524 (Add StaticForeignItem and use it on ForeignItemKind)
- #124540 (Give proof tree visitors the ability to instantiate nested goals directly)
- #124543 (codegen tests: Tolerate `range()` qualifications in enum tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Give proof tree visitors the ability to instantiate nested goals directly
Useful when we want to look at the nested goals but not necessarily visit them (e.g. in select).
r? lcnr
Add StaticForeignItem and use it on ForeignItemKind
This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.
r? `@oli-obk`
cc `@compiler-errors`
coverage: Replace boolean options with a `CoverageLevel` enum
After #123409, and some discussion at https://github.com/rust-lang/rust/issues/79649#issuecomment-2042093553 and #124120, it became clear to me that we should have a unified concept of “coverage level”, instead of having several separate boolean flags that aren't actually independent.
This PR therefore introduces a `CoverageLevel` enum, to replace the existing boolean flags for `branch` and `mcdc`.
The `no-branch` value (for `-Zcoverage-options`) has been renamed to `block`, instructing the compiler to only instrument for block coverage, with no branch coverage or MD/DC instrumentation.
`@rustbot` label +A-code-coverage
cc `@ZhuUx` `@Lambdaris` `@RenjiSann`
Add a note to the ArbitraryExpressionInPattern error
The current "arbitrary expressions aren't allowed in patterns" error is confusing, as it fires for code where it *looks* like a pattern but the compiler still treats it as an expression. That this is due to the `:expr` fragment specifier forcing the expression-ness property on the code.
In the test suite, the "arbitrary expressions aren't allowed in patterns" error can only be found in combination with macro_rules macros that force expression-ness of their content, namely via `:expr` metavariables. I also can't come up with cases where there would be an expression instead of a pattern, so I think it's always coming from an `:expr`.
In order to make the error less confusing, this adds a note explaining the weird `:expr` fragment behaviour.
Fixes#99380
Remove optionality from MoveData::base_local
This is an artifact from when Places could be based on statics and not just locals. Now, all move paths either are locals or have parents, so this doesn't need to return Option anymore.
[Refactor] Rename `Lint` and `LintGroup`'s `is_loaded` to `is_externally_loaded`
The field being named `is_loaded` was very confusing. Turns out it's true for lints that are registered by external tools like Clippy (I had to look at https://github.com/rust-lang/rust/pull/116412 to know what the variable meant). So I renamed `is_loaded` to `is_externally_loaded` and added some docs.
coverage: Avoid hard-coded values when visiting logical ops
This is a tiny little thing that I noticed during the final review of #123409, and I didn't want to hold up the whole PR just for this.
Instead of separately hard-coding the operation being visited, we can get it from the match arm pattern by using an as-pattern.
`@rustbot` label +A-code-coverage
Mark unions non-const-propagatable in `KnownPanicsLint` without calling layout
Fixes#123710
The ICE occurs during the layout calculation of the union `InvalidTag` in #123710 because the following assert fails:5fe8b697e7/compiler/rustc_abi/src/layout.rs (L289-L292)
The layout calculation is invoked by `KnownPanicsLint` when it is trying to figure out which locals it can const prop. Since `KnownPanicsLint` is never actually going to const props unions thanks to PR https://github.com/rust-lang/rust/pull/121628 there's no point calling layout to check if it can. So in this fix I skip the call to layout and just mark the local non-const propagatable if it is a union.
Fix#124478 - offset_of! returns a temporary
This was due to the must_use() call. Adding HIR's `OffsetOf` to the must_use checking within the compiler avoids this issue while maintaining the lint output.
Fixes#124478. `@tgross35`
Use probes more aggressively in new solver
....so that we have the right candidate information when assembling trait and normalizes-to goals.
Also gets rid of misc probes.
r? lcnr
MCDC coverage: support nested decision coverage
#123409 provided the initial MCDC coverage implementation.
As referenced in #124144, it does not currently support "nested" decisions, like the following example :
```rust
fn nested_if_in_condition(a: bool, b: bool, c: bool) {
if a && if b || c { true } else { false } {
say("yes");
} else {
say("no");
}
}
```
Note that there is an if-expression (`if b || c ...`) embedded inside a boolean expression in the decision of an outer if-expression.
This PR proposes a workaround for this cases, by introducing a Decision context stack, and by handing several `temporary condition bitmaps` instead of just one.
When instrumenting boolean expressions, if the current node is a leaf condition (i.e. not a `||`/`&&` logical operator nor a `!` not operator), we insert a new decision context, such that if there are more boolean expressions inside the condition, they are handled as separate expressions.
On the codegen LLVM side, we allocate as many `temp_cond_bitmap`s as necessary to handle the maximum encountered decision depth.
