Add compiletest `--compare-mode nll` option
Before implementing the tidy stuff, I'd appreciate if someone reviews the changes so far.
This is my first non-trivial pull request, so I could really use some feedback. :)
closes#48879.
r? @nikomatsakis
In intercrate mode, if we determine that a particular `T: Trait` is
unknowable, we sometimes also go and get extra causal information. An
errant `?` was causing us to propagate an error found in that process
out as if `T: Trait` was not unknowable but rather not provable. This
led to an ICE.
This commit updates our manifest generation for rustup to filter out any
components/extensions which are actually missing. This is intended to help
mitigate #49462 by making the manifests reflect reality, that many targets now
are missing a `rust-docs` component rather than requiring it exists.
proc_macro: Reorganize public API
This commit is a reorganization of the `proc_macro` crate's public user-facing
API. This is the result of a number of discussions at the recent Rust All-Hands
where we're hoping to get the `proc_macro` crate into ship shape for
stabilization of a subset of its functionality in the Rust 2018 release.
The reorganization here is motivated by experiences from the `proc-macro2`,
`quote`, and `syn` crates on crates.io (and other crates which depend on them).
The main focus is future flexibility along with making a few more operations
consistent and/or fixing bugs. A summary of the changes made from today's
`proc_macro` API is:
* The `TokenNode` enum has been removed and the public fields of `TokenTree`
have also been removed. Instead the `TokenTree` type is now a public enum
(what `TokenNode` was) and each variant is an opaque struct which internally
contains `Span` information. This makes the various tokens a bit more
consistent, require fewer wrappers, and otherwise provides good
future-compatibility as opaque structs are easy to modify later on.
* `Literal` integer constructors have been expanded to be unambiguous as to what
they're doing and also allow for more future flexibility. Previously
constructors like `Literal::float` and `Literal::integer` were used to create
unsuffixed literals and the concrete methods like `Literal::i32` would create
a suffixed token. This wasn't immediately clear to all users (the
suffixed/unsuffixed aspect) and having *one* constructor for unsuffixed
literals required us to pick a largest type which may not always be true. To
fix these issues all constructors are now of the form
`Literal::i32_unsuffixed` or `Literal::i32_suffixed` (for all integral types).
This should allow future compatibility as well as being immediately clear
what's suffixed and what isn't.
* Each variant of `TokenTree` internally contains a `Span` which can also be
configured via `set_span`. For example `Literal` and `Term` now both
internally contain a `Span` rather than having it stored in an auxiliary
location.
* Constructors of all tokens are called `new` now (aka `Term::intern` is gone)
and most do not take spans. Manufactured tokens typically don't have a fresh
span to go with them and the span is purely used for error-reporting
**except** the span for `Term`, which currently affects hygiene. The default
spans for all these constructed tokens is `Span::call_site()` for now.
The `Term` type's constructor explicitly requires passing in a `Span` to
provide future-proofing against possible hygiene changes. It's intended that a
first pass of stabilization will likely only stabilize `Span::call_site()`
which is an explicit opt-in for "I would like no hygiene here please". The
intention here is to make this explicit in procedural macros to be
forwards-compatible with a hygiene-specifying solution.
* Some of the conversions for `TokenStream` have been simplified a little.
* The `TokenTreeIter` iterator was renamed to `token_stream::IntoIter`.
Overall the hope is that this is the "final pass" at the API of `TokenStream`
and most of `TokenTree` before stabilization. Explicitly left out here is any
changes to `Span`'s API which will likely need to be re-evaluated before
stabilization.
All changes in this PR have already been reflected to the [`proc-macro2`],
`quote`, and `syn` crates. New versions of all these crates have also been
published to crates.io.
Once this lands in nightly I plan on making an internals post again summarizing
the changes made here and also calling on all macro authors to give the APIs a
spin and see how they work. Hopefully pending no major issues we can then have
an FCP to stabilize later this cycle!
[`proc-macro2`]: https://docs.rs/proc-macro2/0.3.1/proc_macro2/Closes#49596
These were showing up in tests and in binaries but are trivially optimize-able
away, so add `#[inline]` attributes so LLVM has an opportunity to optimize them
out.
Make queries thread safe
This makes queries thread safe by removing the query stack and making queries point to their parents. Queries write to the query map when starting and cycles are detected by checking if there's already an entry in the query map. This makes cycle detection O(1) instead of O(n), where `n` is the size of the query stack.
This is mostly corresponds to the method I described [here](https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606).
cc @rust-lang/compiler
r? @michaelwoerister
Expand macros in `extern {}` blocks
This permits macro and proc-macro and attribute invocations (the latter only with the `proc_macro` feature of course) in `extern {}` blocks, gated behind a new `macros_in_extern` feature.
A tracking issue is now open at #49476closes#48747
Make queries thread safe
This makes queries thread safe by removing the query stack and making queries point to their parents. Queries write to the query map when starting and cycles are detected by checking if there's already an entry in the query map. This makes cycle detection O(1) instead of O(n), where `n` is the size of the query stack.
This is mostly corresponds to the method I described [here](https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606).
cc @rust-lang/compiler
r? @michaelwoerister
Rollup of 9 pull requests
Successful merges:
- #48658 (Add a generic CAS loop to std::sync::Atomic*)
- #49253 (Take the original extra-filename passed to a crate into account when resolving it as a dependency)
- #49345 (RFC 2008: Finishing Touches)
- #49432 (Flush executables to disk after linkage)
- #49496 (Add more vec![... ; n] optimizations)
- #49563 (add a dist builder to build rust-std components for the THUMB targets)
- #49654 (Host compiler documentation: Include private items)
- #49667 (Add more features to rust_2018_preview)
- #49674 (ci: Remove x86_64-gnu-incremental builder)
Failed merges:
Host compiler documentation: Include private items
Fixes#29893. Now that compiler documentation is being hosted, including private items seems sensible as these types are going to be being used by contributors working on the compiler.
However, including this means that doc comments that contain codeblocks with invalid Rust and can fail the documenting of a given crate (as evidenced by the changes in the second commit included in this PR). We'd need some way of ensuring that this cannot happen so that these failures don't cause documenting to fail. I'm unsure whether this change to documentation steps will cause this to happen already or if something new will be required.
r? @alexcrichton
add a dist builder to build rust-std components for the THUMB targets
the rust-std component only contains the core and compiler-builtins (+c +mem) crates
cc #49382
- I'm not entirely sure if this PR alone will produce rust-std components installable by rustup or if something else needs to be changed
- I could have done the THUMB builds in an existing builder / image; I wasn't sure if that was a good idea so I added a new image
- I could build other crates like alloc into the rust-std component but, AFAICT, that would require calling Cargo a second time (one for alloc and one for compiler-builtins), or have alloc depend on compiler-builtins (#49503 will perform that change) *and* have alloc resurface the "c" and "mem" Cargo features.
r? @alexcrichton
Add more vec![... ; n] optimizations
vec![0; n], via implementations of SpecFromElem, has an optimization that uses with_capacity_zeroed instead of with_capacity, which will use calloc instead of malloc, and avoid an extra memset.
This PR adds the same optimization for ptr::null, ptr::null_mut, and None, when their in-memory representation is zeroes.
Flush executables to disk after linkage
A problem caused by not doing so in Chrome has been reported [here](https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/amp/).
`File::sync_all()` calls `FlushFileBuffers()` down the line, causing potentially unflushed buffers on high I/O-load systems to flush and preventing nasty non-reproducible bugs.
Closes#48545
Add a generic CAS loop to std::sync::Atomic*
This adds two new methods to both `AtomicIsize` and `AtomicUsize` with optimized safe compare-and-set loops, so users will no longer need to write their own, except in *very* strange circumstances.
`update_and_fetch` will apply the function and return its result, whereas `fetch_and_update` will apply the function and return the previous value.
This solves #48384 with `x.update_and_fetch(|x| x.max(y))`. It also relates to #48655 (which I misuse as tracking issue for now)..
*note* This *might* need a crater run because the functions could clash with third party extension traits.
It turns out that the support in #49316 wasn't enough to handle all cases
notably the example in #48661. The underlying bug was connected to panic=abort
where lang items were listed in the `missing_lang_items` sets but didn't
actually exist anywhere.
This caused the linker backend to deduce that start-group/end-group wasn't
needed because not all items were defined. Instead the missing lang items that
don't actually need to have a definition are filtered out and not considered for
the start-group/end-group arguments
Closes#48661
