Auto merge of #49154 - petrochenkov:spident, r=eddyb
AST: Give spans to all identifiers
Change representation of `ast::Ident` from `{ name: Symbol, ctxt: SyntaxContext }` to `{ name: Symbol, span: Span }`.
Syntax contexts still can be extracted from spans (`span.ctxt()`).
Why this should not require more memory:
- `Span` is `u32` just like `SyntaxContext`.
- Despite keeping more spans in AST we don't actually *create* more spans, so the number of "outlined" spans kept in span interner shouldn't become larger.
Why this may be slightly slower:
- When we need to extract ctxt from an identifier instead of just field read we need to do bit field extraction possibly followed by and access by index into span interner's vector. Both operations should be fast (unless the span interner is under some synchronization) and we already do ctxt extraction from spans all the time during macro expansion, so the difference should be lost in noise.
cc https://github.com/rust-lang/rust/pull/48842#issuecomment-373365661
Auto merge of #49293 - memoryleak47:add-compiletest-nll-compare-mode, r=pnkfelix
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.
Alex Crichton [Thu, 5 Apr 2018 18:36:01 +0000 (11:36 -0700)]
Filter out missing components from manifests
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.
Alex Crichton [Thu, 5 Apr 2018 15:49:20 +0000 (10:49 -0500)]
Rollup merge of #49597 - alexcrichton:proc-macro-v2, r=petrochenkov
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!
Auto merge of #49045 - Zoxc:tls, r=michaelwoerister
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).
Alex Crichton [Thu, 5 Apr 2018 15:49:14 +0000 (10:49 -0500)]
Rollup merge of #49350 - abonander:macros-in-extern, r=petrochenkov
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.
Alex Crichton [Thu, 5 Apr 2018 15:49:13 +0000 (10:49 -0500)]
Rollup merge of #49045 - Zoxc:tls, r=michaelwoerister
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).
- #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)
Rollup merge of #49674 - alexcrichton:no-incremental-rustc, r=michaelwoerister
ci: Remove x86_64-gnu-incremental builder
This builder is starting to time out frequently causing PRs to bounce and
otherwise doesn't seem to be catching too many bugs, so this commit removes it
entirely. We've had a number of timeouts in the last few weeks related to this
builder:
On a good run this builder takes about 2h15m, which is already too long for
Travis and the variable build times end up pushing it beyond the 3h limit
occasionally.
The timeouts here are somewhat expected in that an incrementally compiled rustc
compiler isn't optimized like a normal rustc, disallowing inlining between
codegen units and losing lots of optimization opportunities.
Rollup merge of #49654 - davidtwco:issue-29893, r=alexcrichton
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.
Rollup merge of #49563 - japaric:std-thumb, 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.
Rollup merge of #49496 - glandium:master, r=sfackler
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.
Rollup merge of #49432 - nabijaczleweli:master, r=michaelwoerister
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.
Rollup merge of #48658 - llogiq:no-more-cas, r=kennytm
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.
Alex Crichton [Thu, 5 Apr 2018 00:35:42 +0000 (17:35 -0700)]
ci: Remove x86_64-gnu-incremental builder
This builder is starting to time out frequently causing PRs to bounce and
otherwise doesn't seem to be catching too many bugs, so this commit removes it
entirely. We've had a number of timeouts in the last few weeks related to this
builder:
On a good run this builder takes about 2h15m, which is already too long for
Travis and the variable build times end up pushing it beyond the 3h limit
occasionally.
The timeouts here are somewhat expected in that an incrementally compiled rustc
compiler isn't optimized like a normal rustc, disallowing inlining between
codegen units and losing lots of optimization opportunities.
- #49179 (Handle future deprecation annotations )
- #49512 (Add support for variant and types fields for intra links)
- #49515 (fix targetted value background)
- #49516 (Add missing anchor for union type fields)
- #49532 (Add test for rustdoc ignore test)
- #49533 (Add #[must_use] to a few standard library methods)
- #49540 (Fix miri Discriminant() for non-ADT)
- #49559 (Introduce Vec::resize_with method (see #41758))
- #49570 (avoid IdxSets containing garbage above the universe length)
- #49577 (Stabilize String::replace_range)
- #49599 (Fix typo)
- #49603 (Fix url for intra link provided method)
- #49607 (Stabilize iterator methods in 1.27)
- #49609 (run-pass/attr-stmt-expr: expand test cases)
- #49612 (Fix "since" version for getpid feature.)
- #49618 (Fix build error when compiling libcore for 16bit targets)
- #49619 (tweak core::fmt docs)
- #49637 (Stabilize parent_id())
- #49639 (Update Cargo)
- #49628 (Re-write the documentation index)
- #49594 (Add some performance guidance to std::fs and std::io docs)
- #49625 (miri: add public alloc_kind accessor)
- #49634 (Add a test for the fix to issue #43058)
- #49641 (Regression test for #46314)
- #49547 (Unignore borrowck test)
Rollup merge of #49594 - mbrubeck:docs, r=steveklabnik
Add some performance guidance to std::fs and std::io docs
Adds more documentation about performance to various "read" functions in `fs` and `io`, and to `BufReader`/`BufWriter`, with the goal of helping developers choose the best option for a given task.
Rollup merge of #49628 - steveklabnik:learn-use-master, r=QuietMisdreavus
Re-write the documentation index
The docs team has decided that we're framing resources in three ways:
"learning Rust," "using Rust," "mastering Rust." This is a more useful
split than "beginner/intermediate/advanced." As we add more resources
in the future, we expect "using Rust" to grow. "the bookshelf" as a
concept is great, but isn't really organized along these lines. As such,
this reorganizes the docs along these lines.
* a regression is fixed where Cargo would update index on every
operation https://github.com/rust-lang/cargo/pull/5288
* a new unstable `--out-dir` option is implemented
https://github.com/rust-lang/cargo/pull/5203
Auto merge of #48171 - FraGag:doc-copy-clone-impls, r=nikomatsakis
Better document the implementors of Clone and Copy
There are two parts to this change. The first part is a change to the compiler and to the standard library (specifically, libcore) to allow implementations of `Clone` and `Copy` to be written for a subset of builtin types. By adding these implementations to libcore, they now show up in the documentation. This is a [breaking-change] for users of `#![no_core]`, because they will now have to supply their own copy of the implementations of `Clone` and `Copy` that were added in libcore.
The second part is purely a documentation change to document the other implementors of `Clone` and `Copy` that cannot be described in Rust code (yet) and are thus provided by the compiler.
the goal is to build, in a single Cargo invocation, several no-std crates that we want to put in the
rust-std component of no-std targets. The nostd crate builds these crates:
- core
- compiler-builtin (with the "c" and "mem" features enabled)
- alloc
- std_unicode
Auto merge of #48913 - Mark-Simulacrum:rustbuild-test, r=alexcrichton
Add tests to rustbuild
In order to run tests, we cfg out various parts of rustbuild. Generally
speaking, these are filesystem and process-spawning operations. Then, rustbuild
is run "as normal" and the various steps that where run are retrieved from the
cache and checked against the expected results.
Note that this means that the current implementation primarily tests "what" we
build, but doesn't actually test that what we build *will* build. In other
words, it doesn't do any form of dependency verification for any crate. This is
possible to implement, but is considered future work.
This implementation strives to cfg out as little code as possible; it also does
not currently test anywhere near all of rustbuild. The current tests are also
not checked for "correctness," rather, they simply represent what we do as of
this commit, which may be wrong.
Test cases are drawn from the old implementation of rustbuild, though the
expected results may vary.
Rollup merge of #49570 - arielb1:bounded-universe, r=nikomatsakis
avoid IdxSets containing garbage above the universe length
This makes sure that all bits in each IdxSet between the universe length
and the end of the word are all zero instead of being in an indeterminate state.
This fixes a crash with RUST_LOG=rustc_mir, and is probably a good idea
anyway.
r? @nikomatsakis - I think you are responsible for this code area now?
In #41758, the libs team decided they preferred `Vec::resize_with` over `Vec::resize_default()`. Here is an implementation to get this moving forward.
I don't know what the removal process for `Vec::resize_default()` should be, so I've left it in place for now. Would be happy to follow up with its removal.
Rollup merge of #49533 - scottmcm:more-must-use, r=nikomatsakis
Add #[must_use] to a few standard library methods
Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged.
Discuss :)
```rust
warning: unused return value of `std::iter::Iterator::collect` which must be used: if you really need to exhaust the iterator, consider `.for_each(drop)` instead
--> $DIR/fn_must_use_stdlib.rs:19:5
|
LL | "1 2 3".split_whitespace().collect::<Vec<_>>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: unused return value of `std::borrow::ToOwned::to_owned` which must be used: cloning is often expensive and is not expected to have side effects
--> $DIR/fn_must_use_stdlib.rs:21:5
|
LL | "hello".to_owned();
| ^^^^^^^^^^^^^^^^^^^
warning: unused return value of `std::clone::Clone::clone` which must be used: cloning is often expensive and is not expected to have side effects
--> $DIR/fn_must_use_stdlib.rs:23:5
|
LL | String::from("world").clone();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Rollup merge of #49179 - varkor:future-deprecation, r=QuietMisdreavus,GuillaumeGomez
Handle future deprecation annotations
This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version.
(I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)
Auto merge of #48575 - ishitatsuyuki:unix-no-thread, r=alexcrichton
rustc_driver: get rid of the extra thread
**Do not rollup**
We can alter the stack size afterwards on Unix.
Having a separate thread causes poor debugging experience when interrupting with signals. I have to get the backtrace of the all thread, as the main thread is waiting to join doing nothing else. This patch allows me to just run `bt` to get the desired backtrace.
* a regression is fixed where Cargo would update index on every
operation https://github.com/rust-lang/cargo/pull/5288
* a new unstable `--out-dir` option is implemented
https://github.com/rust-lang/cargo/pull/5203
Auto merge of #49573 - glandium:huge-align, r=SimonSapin
Reject huge alignments on macos with system allocator only
ef8804ba277b055fdc3e6d148e680e3c1b597ad8 addressed #30170 by rejecting
huge alignments at the allocator API level, transforming a specific
platform bug/limitation into an enforced API limitation on all
platforms.
This change essentially reverts that commit, and instead makes alloc()
itself return AllocErr::Unsupported when receiving huge alignments.
This was discussed in https://github.com/rust-lang/rust/issues/32838#issuecomment-368348408
and following.
Auto merge of #48333 - aidanhs:aphs-no-place-for-placement, r=nikomatsakis
Remove all unstable placement features
Closes #22181, #27779. Effectively makes the assortment of placement RFCs (rust-lang/rfcs#470, rust-lang/rfcs#809, rust-lang/rfcs#1228) 'unaccepted'. It leaves `box_syntax` and keeps the `<-` token as recognised by libsyntax.
------------------------
I don't know the correct process for unaccepting an unstable feature that was accepted as an RFC so...here's a PR.
Let me preface this by saying I'm not particularly happy about doing this (I know it'll be unpopular), but I think it's the most honest expression of how things stand today. I've been motivated by a [post on reddit](https://www.reddit.com/r/rust/comments/7wrqk2/when_will_box_and_placementin_syntax_be_stable/) which asks when these features will be stable - the features have received little RFC-style design work since the end of 2015 (~2 years ago) and leaving them in limbo confuses people who want to know where they're up to. Without additional design work that needs to happen (see the collection of unresolved questions later in this post) they can't really get stabilised, and I think that design work would be most suited to an RFC rather than (currently mostly unused) experimental features in Rust nightly.
I have my own motivations - it's very simple to 'defeat' placement in debug mode today and I don't want a placement in Rust that a) has no guarantees to work and b) has no plan for in-place serde deserialisation.
There's a quote in [1]: "Ordinarily these uncertainties might lead to the RFC being postponed. [The RFC seems like a promising direction hence we will accept since it] will thus give us immediate experience with the design and help in determining the best final solution.". I propose that there have been enough additional uncertainties raised since then that the original direction is less promising and we should be think about the problem anew.
(a historical note: the first mention of placement (under that name - uninit pointers were earlier) in an RFC AFAIK is [0] in late 2014 (pre-1.0). RFCs since then have built on this base - [1] is a comment in Feb 2015 accepting a more conservative design of the Place* traits - this is back when serde still required aster and seemed to break every other nightly! A lot has changed since then, perhaps placement should too)
------------------------
Concrete unresolved questions include:
- making placement work in debug mode [7]
- making placement work for serde/with fallible creation [5], [irlo2], [8]
- trait design:
- opting into not consuming the placer in `Placer::make_place` - [2]
- trait proliferation - [4] (+ others in that thread)
- fallible allocation - [3], [4] (+ others in that thread)
- support for DSTs/unsized structs (if at all) - [1], [6]
More speculative unresolved questions include:
- better trait design with in the context of future language features [irlo1] (Q11), [irlo3]
- interaction between custom allocators and placement [irlo3]
Auto merge of #48647 - alexcrichton:update-sccache, r=kennytm
Update sccache to its master branch
Ideally I'd like to soon enable sccache for rustbuild itself and some of the
stage0 tools, but for that to work we'll need some better Rust support than the
pretty old version we were previously using!
The docs team has decided that we're framing resources in three ways:
"learning Rust," "using Rust," "mastering Rust." This is a more useful
split than "beginner/intermediate/advanced." As we add more resources
in the future, we expect "using Rust" to grow. "the bookshelf" as a
concept is great, but isn't really organized along these lines. As such,
this reorganizes the docs along these lines.
Mark Simulacrum [Sun, 1 Apr 2018 16:51:24 +0000 (10:51 -0600)]
Stop checking that the graph produced by a dry run is equivalent
This is too likely to cause spurious bounces on CI; what we run may be
dependent on what ran successfully before hand (e.g. RLS features with
Clippy), which makes this not tenable. There's no good way to ignore
specifically these problematic steps so we'll just ignore everything for
the time being. We still test that a dry run worked though so largely
this is the same from a ensure-that-tests-work perspective.
Eventually we'll want to undo this commit, though, to make our tests
more accurate.
Mark Simulacrum [Tue, 27 Mar 2018 14:06:47 +0000 (16:06 +0200)]
Refactor to use a dry-run config instead of cfg(test)
This ensures that each build will support the testing design of "dry
running" builds. It's also checked that a dry run build is equivalent
step-wise to a "wet" run build; the graphs we generate when running are
directly compared node/node and edge/edge, both for order and contents.