Fix handling of FFI arguments
r? @eddyb @nikomatsakis or whoever else.
cc @alexcrichton @rust-lang/core
The strategy employed here was to essentially change code we generate from
```llvm
%s = alloca %S ; potentially smaller than argument, but never larger
%1 = bitcast %S* %s to { i64, i64 }*
store { i64, i64 } %0, { i64, i64 }* %1, align 4
```
to
```llvm
%1 = alloca { i64, i64 } ; the copy of argument itself
store { i64, i64 } %0, { i64, i64 }* %1, align 4
%s = bitcast { i64, i64 }* %1 to %S* ; potentially truncate by casting to a pointer of smaller type.
```
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
Prevents an ice with `(...).f` since the sub-expression is in the AST but not the HIR.
We could actually do better in this specific case, but it doesn't seem worth it.
We've gotten requests to move our Android support as far back as API level 9
where unfortunately the `posix_memalign` API wasn't implemented yet. Thankfully,
however, the `memalign` API was and it appears to be usable with `free` on the
Android platform (see comments included in commit).
This should help fix some of the last few test failures when compiling against
API level 9.
