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.
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`
Remove special-casing for `SimplifiedType` for next solver
It's unnecessary due to the way that we fully normalize the self type before assembly begins.
r? lcnr
These functions are only used in `rustc_builtin_macros`, so it makes
sense for them to live there. This allows them to be changed from `pub`
to `pub(crate)`.
uses a `ProofTreeVisitor` to look into nested
goals when looking at the pending obligations
during hir typeck. Used by closure signature
inference, coercion, and for async functions.
`-Z debug-macros` is "stabilized" by enabling it by default and removing.
`-Z collapse-macro-debuginfo` is stabilized as `-C collapse-macro-debuginfo`.
It now supports all typical boolean values (`parse_opt_bool`) in addition to just yes/no.
Default value of `collapse_debuginfo` was changed from `false` to `external` (i.e. collapsed if external, not collapsed if local).
`#[collapse_debuginfo]` attribute without a value is no longer supported to avoid guessing the default.
Don't ICE when `codegen_select_candidate` returns ambiguity in new solver
Because we merge identical candidates, we may have >1 impl candidate to in `codegen_select_error` but *not* have a trait error.
r? lcnr
Detect borrow error involving sub-slices and suggest `split_at_mut`
```
error[E0499]: cannot borrow `foo` as mutable more than once at a time
--> $DIR/suggest-split-at-mut.rs:13:18
|
LL | let a = &mut foo[..2];
| --- first mutable borrow occurs here
LL | let b = &mut foo[2..];
| ^^^ second mutable borrow occurs here
LL | a[0] = 5;
| ---- first borrow later used here
|
= help: use `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices
```
Address most of #58792.
For follow up work, we should emit a structured suggestion for cases where we can identify the exact `let (a, b) = foo.split_at_mut(2);` call that is needed.
Improved code with clippy
I haven't used the bootstrapped compiler, but I think I have made some improvements using clippy. I have already made the following changes to the compiler:
Replaced `self.first().is_digit(10)` with `self.first().is_ascii_digit()` on lines 633, 664, and 680 of compiler/rust_lexer/src/lib.rs.
Removed unnecessary cast on line 262 of compiler/rustc_lexer/src/unescape.rs
Replaced ok_or_else with ok_or on line 303 of compiler/rustc_lexer/src/unescape.rs
Replaced `!std::env::var("RUSTC_BOOTSTRAP").is_ok()` with `std::env::var("RUSTC_BOOTSTRAP").is_err()` on line 4 of compiler/rustc_macros/build.rs
Removed needless borrow for generic argument `env`on line 53 of compiler/rust_llvm/build.rs
```
error[E0499]: cannot borrow `foo` as mutable more than once at a time
--> $DIR/suggest-split-at-mut.rs:13:18
|
LL | let a = &mut foo[..2];
| --- first mutable borrow occurs here
LL | let b = &mut foo[2..];
| ^^^ second mutable borrow occurs here
LL | a[0] = 5;
| ---- first borrow later used here
|
= help: use `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices
```
Address most of #58792.
For follow up work, we should emit a structured suggestion for cases where we can identify the exact `let (a, b) = foo.split_at_mut(2);` call that is needed.
Enforce closure args + return type are WF
I found this out when investigating https://github.com/rust-lang/rust/issues/123461#issuecomment-2040894359. Turns out we don't register WF obligations for closure args and return types, leading to the ICE.
~~I think this is a useful thing to check for, but I'd like to check what the fallout is.~~ crater is complete.
~~Worst case, I think we should enforce this across an edition boundary (and possibly eventually migrate this for all editions) -- this should be super easy to do, since this is a check in HIR wfcheck, so it can be made edition dependent.~~ I believe the regressions are manageable enough to not necessitate edition-specific behavior.
Fixes#123461
