Unify `Rvalue::Aggregate` paths in cg_ssa
In #123840 and #123886 I added two different codepaths for `Rvalue::Aggregate` in `cg_ssa`.
This merges them into one, since raw pointers are also immediates that can be built from the immediates of their "fields".
Avoid clone in `Comments::next`
`Comments::next`, in `rustc_ast_pretty`, has this comment:
```
// FIXME: This shouldn't probably clone lmao
```
The obvious thing to try is to return `Option<&Comment>` instead of `Option<Comment>`. But that leads to multiple borrows all over the place, because `Comments` must be borrowed from `PrintState` and then processed by `&mut self` methods within `PrintState`.
This PR instead rearranges things so that comments are consumed as they are used, preserving the `Option<Comment>` return type without requiring any cloning.
r? `@compiler-errors`
This span records the declaration of the metavariable in the LHS of the macro.
It's used in a couple of error messages. Unfortunately, it gets in the way of
the long-term goal of removing `TokenKind::Interpolated`. So this commit
removes it, which degrades a couple of (obscure) error messages but makes
things simpler and enables the next commit.
Remove `#[macro_use] extern crate rustc middle` from numerous crates
Because explicit importing of macros via `use` items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. This PR mops up some cases I didn't get to in #124511.
r? `@saethlin`
The current way of stepping through each comment in `Comments` is a bit
weird. There is a `Vec<Comments>` and a `current` index, which is fine.
The `Comments::next` method clones the current comment but doesn't
advance `current`; the advancing instead happens in `print_comment`,
which is where each cloned comment is actually finally used (or not, in
some cases, if the comment fails to satisfy a predicate).
This commit makes things more iterator-like:
- `Comments::next` now advances `current` instead of `print_comment`.
- `Comments::peek` is added so you can inspect a comment and check a
predicate without consuming it.
- This requires splitting `PrintState::comments` into immutable and
mutable versions. The commit also moves the ref inside the `Option` of
the return type, to save callers from having to use `as_ref`/`as_mut`.
- It also requires adding `PrintState::peek_comment` alongside the
existing `PrintState::next_comment`. (The lifetimes in the signature
of `peek_comment` ended up more complex than I expected.)
We now have a neat separation between consuming (`next`) and
non-consuming (`peek`) uses of each comment. As well as being clearer,
this will facilitate the next commit that avoids unnecessary cloning.
Pretty-print let-else with added parenthesization when needed
Rustc used to produce invalid syntax for the following code, which is problematic because it means we cannot apply rustfmt to the output of `-Zunpretty=expanded`.
```rust
macro_rules! expr {
($e:expr) => { $e };
}
fn main() {
let _ = expr!(loop {}) else { return; };
}
```
```console
$ rustc repro.rs -Zunpretty=expanded | rustfmt
error: `loop...else` loops are not supported
--> <stdin>:9:29
|
9 | fn main() { let _ = loop {} else { return; }; }
| ---- ^^^^^^^^^^^^^^^^
| |
| `else` is attached to this loop
|
= note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run
```
Unfortunately, we can't always offer a machine-applicable suggestion when there are subpatterns from macro expansion.
Co-Authored-By: Guillaume Boisseau <Nadrieril@users.noreply.github.com>
solve: all "non-structural" logging to trace
This enables us to start with `RUSTC_LOG=rustc_trait_selection::solve=debug` to figure out *where* something went wrong, to then separately use `trace` to get to the details.
r? ``@compiler-errors``
Fix, document, and test parser and pretty-printer edge cases related to braced macro calls
_Review note: this is a deceptively small PR because it comes with 145 lines of docs and 196 lines of tests, and only 25 lines of compiler code changed. However, I recommend reviewing it 1 commit at a time because much of the effect of the code changes is non-local i.e. affecting code that is not visible in the final state of the PR. I have paid attention that reviewing the PR one commit at a time is as easy as I can make it. All of the code you need to know about is touched in those commits, even if some of those changes disappear by the end of the stack._
This is a follow-up to https://github.com/rust-lang/rust/pull/119105. One case that is not relevant to `-Zunpretty=expanded`, but which came up as I'm porting #119105 and #118726 into `syn`'s printer and `prettyplease`'s printer where it **is** relevant, and is also relevant to rustc's `stringify!`, is statement boundaries in the vicinity of braced macro calls.
Rustc's AST pretty-printer produces invalid syntax for statements that begin with a braced macro call:
```rust
macro_rules! stringify_item {
($i:item) => {
stringify!($i)
};
}
macro_rules! repro {
($e:expr) => {
stringify_item!(fn main() { $e + 1; })
};
}
fn main() {
println!("{}", repro!(m! {}));
}
```
**Before this PR:** output is not valid Rust syntax.
```console
fn main() { m! {} + 1; }
```
```console
error: leading `+` is not supported
--> <anon>:1:19
|
1 | fn main() { m! {} + 1; }
| ^ unexpected `+`
|
help: try removing the `+`
|
1 - fn main() { m! {} + 1; }
1 + fn main() { m! {} 1; }
|
```
**After this PR:** valid syntax.
```console
fn main() { (m! {}) + 1; }
```
Uplift various `*Predicate` types into `rustc_type_ir`
Uplifts `ProjectionPredicate`, `ExistentialTraitRef`, `ExistentialProjection`, `TraitPredicate`, `NormalizesTo`, `CoercePredicate`, and `SubtypePredicate`.
Adds `rustc_type_ir_macros`, which semi-duplicates the derive for `TypeVisitable`, `TypeFoldable`, and `Lift`, but in a way that is interner-agnostic.
Moves `rustc_type_ir::trait_ref` to `rustc_type_ir::predicate`. The specific placement of all these structs doesn't matter b/c of glob imports, tho.
Refactoring after the `PlaceValue` addition
I added [`PlaceValue`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html) in #123775, but kept that one line-by-line simple because it touched so many places.
This goes through to add more helpers & docs, and change some `PlaceRef` to `PlaceValue` where the type didn't need to be included.
No behaviour changes -- the codegen is exactly the same.
It is impossible for expr here to be a braced macro call. Expr comes
from `parse_stmt_without_recovery`, in which macro calls are parsed by
`parse_stmt_mac`. See this part:
let kind = if (style == MacStmtStyle::Braces
&& self.token != token::Dot
&& self.token != token::Question)
|| self.token == token::Semi
|| self.token == token::Eof
{
StmtKind::MacCall(P(MacCallStmt { mac, style, attrs, tokens: None }))
} else {
// Since none of the above applied, this is an expression statement macro.
let e = self.mk_expr(lo.to(hi), ExprKind::MacCall(mac));
let e = self.maybe_recover_from_bad_qpath(e)?;
let e = self.parse_expr_dot_or_call_with(e, lo, attrs)?;
let e = self.parse_expr_assoc_with(
0,
LhsExpr::AlreadyParsed { expr: e, starts_statement: false },
)?;
StmtKind::Expr(e)
};
A braced macro call at the head of a statement is always either extended
into ExprKind::Field / MethodCall / Await / Try / Binary, or else
returned as StmtKind::MacCall. We can never get a StmtKind::Expr
containing ExprKind::MacCall containing brace delimiter.
The change to the test is a little goofy because the compiler was
guessing "correctly" before that `falsy! {}` is the condition as opposed
to the else body. But I believe this change is fundamentally correct.
Braced macro invocations in statement position are most often item-like
(`thread_local! {...}`) as opposed to parenthesized macro invocations
which are condition-like (`cfg!(...)`).
I didn't figure out how to reach this condition with `expr` containing
`ExprKind::MacCall`. All the approaches I tried ended up with the macro
call ending up in the `StmtKind::MacCall` case below instead.
In any case, from visual inspection this is a bugfix. If we do end up
with a `StmtKind::Expr` containing `ExprKind::MacCall` with brace
delimiter, it would not need ";" printed after it.
This commit by itself is supposed to have no effect on behavior. All of
the call sites are updated to preserve their previous behavior.
The behavior changes are in the commits that follow.
For each of these, we need to decide whether they need to be using
`expr_requires_semi_to_be_stmt`, or `expr_requires_comma_to_be_match_arm`,
which are supposed to be 2 different behaviors. Previously they were
conflated into one, causing either too much or too little
parenthesization.
Refactor Apple `target_abi`
This was bundled together with `Arch`, which complicated a few code paths and meant we had to do more string matching than necessary.
CC `@BlackHoleFox` as you've worked on the Apple target spec before
Related: Is there a reason why `Target`/`TargetOptions` use `StaticCow` for so many things, instead of an enum with defined values (and perhaps a catch-all case for custom target json files)? Tagging `@Nilstrieb,` as you might know?
Update ena to 0.14.3
Includes https://github.com/rust-lang/ena/pull/53, which removes a trivial `Self: Sized` bound that prevents `ena` from building on the new solver.
I added `PlaceValue` in 123775, but kept that one line-by-line simple because it touched so many places.
This goes through to add more helpers & docs, and change some `PlaceRef` to `PlaceValue` where the type didn't need to be included.
No behaviour changes.
Rollup of 5 pull requests
Successful merges:
- #124233 (Add `-lmingwex` second time in `mingw_libs`)
- #124318 (ignore generics args in attribute paths)
- #124899 (bootstrap: add comments for the automatic dry run)
- #124904 (reachable computation: extend explanation of what this does, and why)
- #124930 (Make sure we consume a generic arg when checking mistyped turbofish)
r? `@ghost`
`@rustbot` modify labels: rollup
Make sure we consume a generic arg when checking mistyped turbofish
When recovering un-turbofish-ed args in expr position (e.g. `let x = a<T, U>();` in `check_mistyped_turbofish_with_multiple_type_params`, we used `parse_seq_to_before_end` to parse the fake generic args; however, it used `parse_generic_arg` which *optionally* parses a generic arg. If it doesn't end up parsing an arg, it returns `Ok(None)` and consumes no tokens. If we don't find a delimiter after this (`,`), we try parsing *another* element. In this case, we just infinitely loop looking for a subsequent element.
We can fix this by making sure that we either parse a generic arg or error in `parse_seq_to_before_end`'s callback.
Fixes#124897
reachable computation: extend explanation of what this does, and why
Follow-up to https://github.com/rust-lang/rust/pull/122769. I had the time to think about this some more, in particular in the context of https://github.com/rust-lang/rust/issues/119214, so I felt it was worth extending these comments some more.
I also gave up on the context of "externally reachable" as it is not called that way anywhere else in the compiler.
Cc `@tmiasko` `@saethlin`
ignore generics args in attribute paths
Fixes#97006Fixes#123911Fixes#123912
This patch ensures that we no longer have to handle invalid generic arguments in attribute paths.
r? `@petrochenkov`
Add `-lmingwex` second time in `mingw_libs`
Upcoming mingw-w64 releases will contain small math functions refactor which moved implementation around. As a result functions like `lgamma`
now depend on libraries in this order:
`libmingwex.a` -> `libmsvcrt.a` -> `libmingwex.a`.
Fixes#124221
Avoid `alloca`s in codegen for simple `mir::Aggregate` statements
The core idea here is to remove the abstraction penalty of simple newtypes in codegen.
Even something simple like constructing a
```rust
#[repr(transparent)] struct Foo(u32);
```
forces an `alloca` to be generated in nightly right now.
Certainly LLVM can optimize that away, but it would be nice if it didn't have to.
Quick example:
```rust
#[repr(transparent)]
pub struct Transparent32(u32);
#[no_mangle]
pub fn make_transparent(x: u32) -> Transparent32 {
let a = Transparent32(x);
a
}
```
on nightly we produce <https://rust.godbolt.org/z/zcvoM79ae>
```llvm
define noundef i32 `@make_transparent(i32` noundef %x) unnamed_addr #0 {
%a = alloca i32, align 4
store i32 %x, ptr %a, align 4
%0 = load i32, ptr %a, align 4, !noundef !3
ret i32 %0
}
```
but after this PR we produce
```llvm
define noundef i32 `@make_transparent(i32` noundef %x) unnamed_addr #0 {
start:
ret i32 %x
}
```
(even before the optimizer runs).
Rename some `FulfillmentErrorCode`/`ObligationCauseCode` variants to be less redundant
1. Rename some `FulfillmentErrorCode` variants.
2. Always use `ObligationCauseCode::` to prefix a code, rather than using a glob import and naming them through `traits::`.
3. Rename some `ObligationCauseCode` variants -- I wasn't particularly thorough with thinking of a new names for these, so could workshop them if necessary.
4. Misc stuff from renaming.
r? lcnr
Rollup of 5 pull requests
Successful merges:
- #124615 (coverage: Further simplify extraction of mapping info from MIR)
- #124778 (Fix parse error message for meta items)
- #124797 (Refactor float `Primitive`s to a separate `Float` type)
- #124888 (Migrate `run-make/rustdoc-output-path` to rmake)
- #124957 (Make `Ty::builtin_deref` just return a `Ty`)
r? `@ghost`
`@rustbot` modify labels: rollup
Refactor float `Primitive`s to a separate `Float` type
Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`.
As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`.
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
Fix parse error message for meta items
Addresses https://github.com/rust-lang/rust/issues/122796#issuecomment-2010803906, cc [``@]Thomasdezeeuw.``
For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`):
```
error: expected unsuffixed literal or identifier, found `ident`
--> weird.rs:6:19
|
6 | #[cfg(feature = $ident)]
| ^^^^^^
...
11 | m!(id);
| ------ in this macro invocation
|
= note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info)
```
This was incorrect and caused confusion, justifiably so (see #122796).
In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers.
Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens:
```
error: expected unsuffixed literal, found `-`
--> weird.rs:16:17
|
16 | #[cfg(feature = -1)]
| ^
|
help: surround the identifier with quotation marks to parse it as a string
|
16 | #[cfg(feature =" "-1)]
| + +
```
Now we no longer do.
coverage: Further simplify extraction of mapping info from MIR
This is another round of rearrangement and simplification that builds on top of the changes made to mapping-extraction by #124603.
The overall theme is to take the computation of `bcb_has_mappings` and `test_vector_bitmap_bytes` out of the main body of `generate_coverage_spans`, which then lets us perform a few other small changes that had previously been held up by the need to work around those computations.
codegen: memmove/memset cannot be non-temporal
non-temporal memset is not a thing.
And for memmove, since the LLVM backend doesn't support this, surely we don't need it in the GCC backend.
Some minor (English only) heroics are performed to print error messages
like "5th rule of macro `m` is never used". The form "rule #5 of macro
`m` is never used" is just as good and much simpler to implement.
Eliminate some `FIXME(lcnr)` comments
In some cases this involved changing code. In some cases the comment was able to removed or replaced.
r? ``@lcnr``
Rename `Generics::params` to `Generics::own_params`
I hope this makes it slightly more obvious that `generics.own_params` is insufficient when considering nested items. I didn't actually audit any of the usages, for the record.
r? lcnr
`InferCtxt::next_{ty,const}_var*` all take an origin, but the
`param_def_id` is almost always `None`. This commit changes them to just
take a `Span` and build the origin within the method, and adds new
methods for the rare cases where `param_def_id` might not be `None`.
This avoids a lot of tedious origin building.
Specifically:
- next_ty_var{,_id_in_universe,_in_universe}: now take `Span` instead of
`TypeVariableOrigin`
- next_ty_var_with_origin: added
- next_const_var{,_in_universe}: takes Span instead of ConstVariableOrigin
- next_const_var_with_origin: added
- next_region_var, next_region_var_in_universe: these are unchanged,
still take RegionVariableOrigin
The API inconsistency (ty/const vs region) seems worth it for the
large conciseness improvements.
`InferCtxt::next_{ty,const,int,float}_var_id` each have a single call
site, in `InferCtt::next_{ty,const,int,float}_var` respectively.
The only remaining method that creates a var_id is
`InferCtxt::next_ty_var_id_in_universe`, which has one use outside the
crate.
Make `#![feature]` suggestion MaybeIncorrect
Fixes https://github.com/rust-lang/rust-clippy/issues/12784
The `unstable_name_collisions` lint uses `disabled_nightly_features` to mention the feature name, but accepting the suggestion would result in an ambiguity error
There are other calls where accepting the feature gate would fix code when ran with `cargo fix --broken-code`, though it's not always desirable to add a feature gate even if the user is currently on nightly so MaybeIncorrect seems appropriate
Add `ErrorGuaranteed` to `Recovered::Yes` and use it more.
The starting point for this was identical comments on two different fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
// FIXME: investigate making this a `Option<ErrorGuaranteed>`
recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed` to `Recovered::Yes`. Then I ended up using `Recovered` instead of `Option<ErrorGuaranteed>` for these two places and elsewhere, which required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.
This makes things more consistent, because `Recovered` is used in more places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible to set `recovered` to `Recovered::Yes` without having emitted an error.
r? `@oli-obk`
Fix#124819, where a if-less block causes a wrong output. It is
caused by get_return_block in get_fn_decl. In get_return_block,
when a else-less if expression is the tail expression, the check
for next_node will keep iterating. So it is necessary to make a
early return in the check.
The comment mentions that `ReBound` and `ReVar` aren't expected here.
Experimentation with the full test suite indicates this is true, and
that `ReErased` also doesn't occur. So the commit introduces `bug!` for
those cases. (If any of them show up later on, at least we'll have a
test case.)
The commit also remove the first sentence in the comment.
`RePlaceholder` is now handled in the match arm above this comment and
nothing is printed for it, so that sentence is just wrong. Furthermore,
issue #13998 was closed some time ago.
The starting point for this was identical comments on two different
fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
// FIXME: investigate making this a `Option<ErrorGuaranteed>`
recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed`
to `Recovered::Yes`. Then I ended up using `Recovered` instead of
`Option<ErrorGuaranteed>` for these two places and elsewhere, which
required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.
This makes things more consistent, because `Recovered` is used in more
places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible
to set `recovered` to `Recovered::Yes` without having emitted an error.
Do not add leading asterisk in the `PartialEq`
I think we should address this issue, however I am not exactly sure, if this is the right way to do it. It is related to the #123056.
Imagine the simplified code:
```rust
trait MyTrait {}
impl PartialEq for dyn MyTrait {
fn eq(&self, _other: &Self) -> bool {
true
}
}
#[derive(PartialEq)]
enum Bar {
Foo(Box<dyn MyTrait>),
}
```
On the nightly compiler, the `derive` produces invalid code with the weird error message:
```
error[E0507]: cannot move out of `*__arg1_0` which is behind a shared reference
--> src/main.rs:11:9
|
9 | #[derive(PartialEq)]
| --------- in this derive macro expansion
10 | enum Things {
11 | Foo(Box<dyn MyTrait>),
| ^^^^^^^^^^^^^^^^ move occurs because `*__arg1_0` has type `Box<dyn MyTrait>`, which does not implement the `Copy` trait
|
= note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)
```
It may be related to the perfect derive problem, although requiring the _type_ to be `Copy` seems unfortunate because it is not necessary. Besides, we are adding the extra dereference only for the diagnostics?
Handle field projections like slice indexing in invalid_reference_casting
r? `@Urgau`
I saw the implementation in https://github.com/rust-lang/rust/pull/124761, and I was wondering if we also need to handle field access. We do. Without this PR, we get this errant diagnostic:
```
error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
--> /home/ben/rust/tests/ui/lint/reference_casting.rs:262:18
|
LL | let r = &mut v.0;
| --- backing allocation comes from here
LL | let ptr = r as *mut i32 as *mut Vec3<i32>;
| ------------------------------- casting happend here
LL | unsafe { *ptr = Vec3(0, 0, 0) }
| ^^^^^^^^^^^^^^^^^^^^
|
= note: casting from `i32` (4 bytes) to `Vec3<i32>` (12 bytes)
```
Fix more ICEs in `diagnostic::on_unimplemented`
There were 8 other calls to `expect_local` left in `on_unimplemented.rs` -- all of which (afaict) could be turned into ICEs.
I would really like to see validation of `on_unimplemented` separated from parsing, so we only emit errors here:
a60f077c38/compiler/rustc_hir_analysis/src/check/check.rs (L836-L839)
...And gracefully fail instead when emitting trait predicate failures, not *ever* even trying to emit an error or a lint. But that's left for a separate PR.
r? `@estebank`
Fix Error Messages for `break` Inside Coroutines
Fixes#124495
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`.~~
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.
- Fixed std support in top-level docs.
- Added `*-apple-darwin` docs.
- Added `i686-apple-darwin` docs.
- Moved `aarch64-apple-ios-sim` to `*-apple-ios` and document all the
iOS targets there.
- Added `*-apple-ios-macabi` docs.
- Add myself (madsmtm) as co-maintainer of most of these targets.
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.
Add decision_depth field to TVBitmapUpdate/CondBitmapUpdate statements
Add decision_depth field to BcbMappingKinds MCDCBranch and MCDCDecision
Add decision_depth field to MCDCBranchSpan and MCDCDecisionSpan
Rename `inhibit_union_abi_opt()` to `inhibits_union_abi_opt()`
`inihibit` seems to suggest that this function will inhibit optimizations whereas `inhibits` correctly indicates that it will merely _check_ that. With `inhibits` if conditions read more naturally e.g.:
```rust
if repr.inhibits_union_abi_opt() {
}
```
Record certainty of `evaluate_added_goals_and_make_canonical_response` call in candidate
Naming subject to bikeshedding, but I will need this when moving `select` to a proof tree visitor.
r? lcnr
Do not ICE on invalid consts when walking mono-reachable blocks
The `bug!` here was written under the logic of "this condition is impossible, right?" except that of course, if the compiler is given code that results in an compile error, then the situation is possible.
So now we just direct errors into the already-existing path for when we can't do a mono-time optimization.
Fix ICE on invalid const param types
Fixes ICE #123863 which occurs because the const param has a type which is not a `bool`, `char` or an integral type.
The ICEing code path begins here in `typeck_with_fallback`: cb3752d20e/compiler/rustc_hir_typeck/src/lib.rs (L167)
The `fallback` invokes the `type_of` query and that eventually ends up calling `ct_infer` from the lowering code over here:
cb3752d20e/compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs (L561) and `ct_infer` ICEs at this location: cb3752d20e/compiler/rustc_hir_analysis/src/collect.rs (L392)
To fix the ICE it I'm triggering a `span_delayed_bug` before we hit `ct_infer` if the type of the const param is not one of the supported types
### Edit
On `@lcnr's` suggestion I've changed the approach to not let `ReStatic` region hit the `bug!` in `ct_infer` instead of triggering a `span_delayed_bug`.
Fix substitution parts having a shifted underline in some cases
If two suggestions parts are side by side, the underline's offset:
(WIP PR as an example, not yet pushed)
```
error: expected a pattern, found an expression
--> ./main.rs:4:9
|
4 | 1 + 2 => 3
| ^^^^^ arbitrary expressions are not allowed in patterns
|
help: check the value in an arm guard
|
4 | n if n == 1 + 2 => 3
| ~ +++++++++++++
```
The emitter didn't take into account that the string had shrunk/grown if two substitution parts were side-by-side (surprisingly, there was only one case in the ui testsuite.)
```
help: check the value in an arm guard
|
4 | n if n == 1 + 2 => 3
| ~ +++++++++++++
```
``@rustbot`` label +A-suggestion-diagnostics
ast: Generalize item kind visiting
And avoid duplicating logic for visiting `Item`s with different kinds (regular, associated, foreign).
The diff is better viewed with whitespace ignored.
resolve: Remove two cases of misleading macro call visiting
Macro calls are ephemeral, they should not add anything to the definition tree, even if their AST could contains something with identity.
Thankfully, macro call AST cannot contain anything like that, so these walks are just noops.
In majority of other places in def_collector / build_reduced_graph they are already not visited.
(Also, a minor match reformatting is included.)
`obligations_for_self_ty`: use `ProofTreeVisitor` for nested goals
As always, dealing with proof trees continues to be a hacked together mess. After this PR and #124380 the only remaining blocker for core is https://github.com/rust-lang/trait-system-refactor-initiative/issues/90. There is also a `ProofTreeVisitor` issue causing an ICE when compiling `alloc` which I will handle in a separate PR. This issue likely affects coherence diagnostics more generally.
The core idea is to extend the proof tree visitor to support visiting nested candidates without using a `probe`. We then simply recurse into nested candidates if they are the only potentially applicable candidate for a given goal and check whether the self type matches the expected one.
For that to work, we need to improve `CanonicalState` to also handle unconstrained inference variables created inside of the trait solver. This is done by extending the `var_values` of `CanoncalState` with each fresh inference variables. Furthermore, we also store the state of all inference variables at the end of each probe. When recursing into `InspectCandidates` we then unify the values of all these states.
r? `@compiler-errors`
