CI: remove `master` job
It only had one job (pun intended), to publish the toolstate. We could probably do that at the end of `auto` builds instead, which is what is done in this PR.
r? `@pietroalbini`
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
Fix ESP IDF build broken by #124210
Subject says it all I hope.
Fix is trivial, thanks to the contributors of #124210 really considering these Tier 3 targets in their change-set (even if ESP IDF was accidentally omitted).
Update `is_val_statically_known` Docs
* Add `Type Requirements` section, listing the allowed inputs, as requested by #121115
* Add `Pointers` subsection, explaining is_val_statically_known handles pointers.
* Add `Stability concerns` section, referring to other documentation relating to consistency in `const` functions.
Fixes#121115
Sorry this took so long.
Port `print-cfg` run-make test to Rust-based rmake.rs
This PR port the `print-cfg` run-make test to Rust-based rmake.rs tests.
The actual test is now split in two:
- the first part for the `--print=cfg` part
- and the second part for the `=PATH` part of `--print`
Part of #121876.
r? `@jieyouxu`
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
drop deprecated value `if-available` for `download-ci-llvm` option
It's been 5 months since we deprecated this. It should be fine to drop its support now.
Abort a process when FD ownership is violated
When an owned FD has already been closed before it's dropped that means something else touched an FD in ways it is not allowed to. At that point things can already be arbitrarily bad, e.g. clobbered mmaps. Recovery is not possible.
All we can do is hasten the fire.
Unlike the previous attempt in #124130 this shouldn't suffer from the possibility that FUSE filesystems can return arbitrary errors.
Bootstrap: Check validity of `--target` and `--host` triples before starting a build
Resolves#122128
As described in the issue, validating the `target` and `host` triples would save a lot of time before actually starting a build. This would also check for custom targets by looking for a valid JSON spec if the specified target does not exist in the [supported](42825768b1/compiler/rustc_target/src/spec/mod.rs (L1401-L1689)) list of targets.
Unconditionally call `really_init` on GNU/Linux
This makes miri not diverge in behavior, it fixes running Rust linux-gnu binaries on musl with gcompat, it fixes dlopen edge-cases that cranelift somehow hits, etc.
Fixes#124126
thou hast gazed into this abyss with me:
r? ``@ChrisDenton``
bootstrap: Document `struct Builder` and its fields
I'm exploring the code of bootstrap and had a bit of a hard time understanding exactly what `Builder` is for at first. I decided to help document it and its field to help future explorers.
bootstrap: Describe build_steps modules
One of my preferred ways to understand source code is to start with its API. This implies the code is documented reasonably accurately, even if it is a private API. The description of one of these modules had not been updated since 2015 and so was both terse and confusing, so I rewrote it. Then I noticed many others went unremarked, so I offered some remarks.
