Fixes to mir dataflow
Fixes to mir dataflow
This collects a bunch of changes to `rustc_borrowck::borrowck::dataflow` (which others have pointed out should probably migrate to some crate that isn't tied to the borrow-checker -- but I have not attempted that here, especially since there are competing approaches to dataflow that we should also evaluate).
These changes:
1. Provide a family of related analyses: MovingOutStatements (which is what the old AST-based dataflo computed), as well as MaybeInitialized, MaybeUninitalized, and DefinitelyInitialized.
* (The last two are actually inverses of each other; we should pick one and drop the other.)
2. Fix bugs in the pre-existing analysis implementation, which was untested and thus some obvious bugs went unnoticed, which brings us to the third point:
3. Add a unit test infrastructure for the MIR dataflow analysis.
* The tests work by adding a new intrinsic that is able to query the analysis state for a particular expression (technically, a particular L-value).
* See the examples in compile-fail/mir-dataflow/inits-1.rs and compile-fail/mir-dataflow/uninits-1.rs
* These tests are only checking the results for MaybeInitialized, MaybeUninitalized, and DefinitelyInitialized; I am not sure if it will be feasible to generalize this testing strategy to the MovingOutStatements dataflow operator.
Make sure that macros that didn't pass LHS checking are not expanded.
This avoid duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros.
Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).
Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.
There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.
cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
Also got rid of the `trait HasMoveData`, since I am now just imposing
the constraint that `BitDenotation<Ctxt=MoveData<'tcx>>` where
necessary instead.
Changed toggle all sections key to `T`
Allows both `T` and `t`.
It had been [Shift]+[+] before.
In response to #33791.
cc @Manishearth
r? @GuillaumeGomez
Improve the long explanation of E0207.
The previous explanation does not seem to explain what it means for an
implementation parameter to be used or unused. The new explanation lists
the three ways specific ways by which an impl parameter becomes constrained
(taken from RFC 447).
This also adds a link to RFC 447.
The explanation has two different examples. The first is adapted from RFC 447,
and shows an instance of E0207 on a impl for a type. The second one is a trait
impl example adapted from issue #22834.
Closes#33650
cc #32777
r? @GuillaumeGomez
Add --enable-local-rebuild to bootstrap from the current release
In Linux distributions, it is often necessary to rebuild packages for cases like applying new patches or linking against new system libraries. In this scenario, the rustc in the distro build environment may already match the current release that we're trying to rebuild. Thus we don't want to use the prior release's bootstrap key, nor `--cfg stage0` for the prior unstable features.
The new `configure --enable-local-rebuild` option specifies that we are rebuilding from the current release. The current bootstrap key is used for the local rustc, and current stage1 features are also assumed. Both the makefiles and rustbuild support this configuration.
Fixes#29556
r? @alexcrichton
Deprecate {f32,f64}::abs_sub.
The abs_sub name is misleading: the function actually computes the
positive difference (`fdim` in C), not the `(x - y).abs()` that *many* people expect
from the name.
This function can be replaced with just `(x - y).max(0.0)`, mirroring
the `abs` version, but this behaves differently with NAN: `NAN.max(0.0)
== 0.0`, while `NAN.positive_diff(0.0) == NAN`. People who absolutely
need that behaviour can use the C function directly and/or talk to the libs
team (we haven't encountered a concrete use-case for this functionality).
Closes#30315.
The previous explanation does not seem to explain what it means for an
implementation parameter to be used or unused. The new explanation lists
the three ways specific ways by which an impl parameter becomes constrained
(taken from RFC 447).
This also adds a link to RFC 447.
The explanation has two different examples. The first is adapted from RFC 447,
and shows an instance of E0207 on a impl for a type. The second one is a trait
impl example adapted from issue #22834.
Closes#33650
As some drive-by's:
* moved bitwise operators into `mod bitslice`
* factored out `fn gen` and `fn kill` methods on `BlockSets` type
* removed outdated comment about `fn propagate_call_return`
Allow `concat_idents!` in type positions as well as in expression positions
This allows the `concat_idents!` macro in type positions as well as in expression positions.
r? @nrc
