Trait documentation clarifications
Hi! I've felt a bit of friction lately in figuring out how to write custom implementations of the `derive`able traits, so I decided to add to the docs :)
The docs for `Copy` are already excellent-- clear, useful sections that I only reordered a bit-- they're now:
* General explanation
* When can my type be `Copy`?
* When can my type _not_ be `Copy`?
* When should my type be `Copy`?
* Derivable
* How can I implement `Copy`?
I didn't add all these sections for all the traits, but I did make sure all the derivable traits had a consistent "Derivable" section that explained what the derived implementation does and a "How can I implement" section that has an example.
Please check me for correctness-- I tried to do research to make sure I was saying accurate things but I'm still learning! ❤️ I'd also love suggestions on information to add that is still missing-- I think these traits are important and deserve to have awesome docs!
Fix `asm-misplaced-option` on ARM/AArch64
This fixesrust-lang/rust#33737. Of course, since we don't run `make check` for ARM cross builds, you probably won't notice it.
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
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
