Currently, after a CALL terminator is created in MIR, we insert DROP
statements for all of its operands -- even though they were just moved
shortly before! These spurious drops are later removed, but not before
causing borrow check errors.
This PR series modifies the drop code to track operands that were
moved and avoid creating drops for them.
Right now, I'm only using this mechanism for calls, but it seems
likely it could be used in more places.
Previously when building documentation for the standard library we'd
copy all the files 5 times, and these files include libcore/libstd docs
which are huge! This commit instead only copies the files after rustdoc
has been run for each crate, reducing the number of redundant copies
we're making.
Looks like the packaging step for the standard library was happening
twice on CI, but it only needs to happen once! The `Analysis` packaging
step accidentally packaged `Std` instead of relying on compiling `Std`,
which meant that we ended up packaging it twice erroneously.
Looks like `script`, which uses `cmd.exe`, doesn't have fail-fast
behavior and if a leading command fails the script doesn't actually fail
so long as the last command succeeds. We instead want the opposite
behavior where if any step fails the whole script fails.
I don't really know `cmd.exe` that well, nor powershell, so I've opted
to move everything to `bash` which should be a good common denominator
amongst all platforms to work with. Additionally I know that `set -e`
works to cause scripts to fail fast.
Note that some scripts remain as `script` since they don't appear to
work in` bash`. I'm not really sure why but I reorganized them slightly
to have the "meaty command" run at the end.
This commit changes our CI to use two separate IAM users to
authenticate with AWS:
* ci--rust-lang--rust--sccache: has access to the rust-lang-ci-sccache2
S3 bucket and its credentials are available during the whole build.
* ci--rust-lang--rust--upload: has access to the rust-lang-ci2 S3 bucket
and its credentials are available just during the upload step.
The new tokens are available in the `prod-credentials` library.
A more generic interface for dataflow analysis
#64470 requires a transfer function that is slightly more complex than the typical `gen`/`kill` one. Namely, it must copy state bits between locals when assignments occur (see #62547 for an attempt to make this fit into the existing framework). This PR contains a dataflow interface that allows for arbitrary transfer functions. The trade-off is efficiency: we can no longer coalesce transfer functions for blocks and must visit each statement individually while iterating to fixpoint.
Another issue is that poorly behaved transfer functions can result in an analysis that fails to converge. `gen`/`kill` sets do not have this problem. I believe that, in order to guarantee convergence, flipping a bit from `false` to `true` in the entry set cannot cause an output bit to go from `true` to `false` (negate all preceding booleans when `true` is the bottom value). Perhaps someone with a more formal background can confirm and we can add a section to the docs?
This approach is not maximally generic: it still requires that the lattice used for analysis is the powerset of values of `Analysis::Idx` for the `mir::Body` of interest. This can be done at a later date. Also, this is the bare minimum to get #64470 working. I've not adapted the existing debug framework to work with the new analysis, so there are no `rustc_peek` tests either. I'm planning to do this after #64470 is merged.
Finally, my ultimate plan is to make the existing, `gen`/`kill`-based `BitDenotation` a special case of `generic::Analysis`. Currently they share a ton of code. I should be able to do this without changing any implementers of `BitDenotation`. Something like:
```rust
struct GenKillAnalysis<A: BitDenotation> {
trans_for_block: IndexVec<BasicBlock, GenKillSet<A::Idx>>,
analysis: A,
}
impl<A> generic::Analysis for GenKillAnalysis<A> {
// specializations of `apply_{partial,whole}_block_effect`...
}
```
r? @pnkfelix
Polonius: more `ui` test suite fixes
Since #62736, new tests have been added, and the `run-pass` suite was merged into the `ui` suite.
This PR adds the missing tests expectations for Polonius, and updates the existing ones where the NLL output has changed in some manner (e.g. ordering of notes)
Those are the trivial cases, but a more-detailed explanation is available [in this write-up](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?both#26-async-awaitasync-borrowck-escaping-closure-errorrs-outputs-from-NLL-Polonius-diff) starting at test case 26: they are only differing in diagnostics and instances of other existing test cases differences.
Only 3 of the 9020 tests are still "failing" at the moment (1 failure, 2 OOMs).
r? @nikomatsakis
Fixes#64590
When we emit an 'unreachable' lint, we now add a note pointing at the
expression that actually causes the code to be unreachable (e.g.
`return`, `break`, `panic`).
This is especially useful when macros are involved, since a diverging
expression might be hidden inside of a macro invocation.
`Compiler::compile()` is different to all the other `Compiler` methods
because it lacks a `Queries` entry. It only has one call site, which is
in a test that doesn't need its specific characteristics.
This patch replaces that call with a call to `Compile::link()`, which is
similar enough for the test's purposes. It also notes that the method is
an illustrative example of how `Compiler` can be used.
The super-hot call site of `inlined_shallow_resolve()` basically does
`r.inlined_shallow_resolve(ty) != ty`. This commit introduces a
version of that function specialized for that particular call pattern,
`shallow_resolve_changed()`. Incredibly, this reduces the instruction
count for `keccak` by 5%.
The commit also renames `inlined_shallow_resolve()` as
`shallow_resolve()` and removes the `inline(always)` annotation, as it's
no longer nearly so hot.
Replace `state_for_location` with `DataflowResultsCursor`
These are two different ways of getting the same data from the result of a dataflow analysis. However, `state_for_location` goes quadratic if you try to call it for every statement in the body.
PR: documentation spin loop hint
The documentation for 'spin loop hint' explains that yield is better if the lock holder is running on the same CPU. I suggest that 'CPU or core' would be clearer.
Make rustc_mir::dataflow module pub (for clippy)
I'm working on fixing false-positives of a MIR-based clippy lint (https://github.com/rust-lang/rust-clippy/pull/4509), and in need of the dataflow infrastructure.
