bors [Mon, 13 May 2019 00:28:38 +0000 (00:28 +0000)]
Auto merge of #60630 - nnethercote:use-Symbol-more, r=petrochenkov
Use `Symbol` more
A `Symbol` can be equated with a string (e.g. `&str`). This involves a
TLS lookup to get the chars (and a Mutex lock in a parallel compiler)
and then a char-by-char comparison. This functionality is convenient but
avoids one of the main benefits of `Symbol`s, which is fast equality
comparisons.
This PR removes the `Symbol`/string equality operations, forcing a lot
of existing string occurrences to become `Symbol`s. Fortunately, these
are almost all static strings (many are attribute names) and we can add
static `Symbol`s as necessary, and very little extra interning occurs.
The benefits are (a) a slight speedup (possibly greater in a parallel
compiler), and (b) the code is a lot more principled about `Symbol` use.
The main downside is verbosity, particularly with more `use
syntax::symbol::symbols` items.
bors [Sun, 12 May 2019 20:28:19 +0000 (20:28 +0000)]
Auto merge of #60767 - Centril:rollup-4cbsb73, r=Centril
Rollup of 4 pull requests
Successful merges:
- #60694 (Fix HIR printing of existential type #60662)
- #60750 (syntax: Remove some legacy nonterminal tokens)
- #60751 (Assorted cleanup in parser & AST validation)
- #60752 (Fix minor typos for ItemLocalId)
Matthew Jasper [Sun, 12 May 2019 17:51:40 +0000 (18:51 +0100)]
Don't allow any ReScope in impl trait types
This shouldn't be possible any more, but if it does happen, emit an
error rather than maybe panicking later when NLL finds a the ReScope.
Impl trait in bindings is sufficiently broken that I don't think this
breaks anything that works for it.
bors [Sun, 12 May 2019 17:44:06 +0000 (17:44 +0000)]
Auto merge of #60679 - petrochenkov:lit2, r=matklad
Keep original literal tokens in AST
The original literal tokens (`token::Lit`) are kept in AST until lowering to HIR.
The tokens are kept together with their lowered "semantic" representation (`ast::LitKind`), so the size of `ast::Lit` is increased (this also increases the size of meta-item structs used for processing built-in attributes).
However, the size of `ast::Expr` stays the same.
The intent is to remove the "semantic" representation from AST eventually and keep literals as tokens until lowering to HIR (at least), and I'm going to work on that, but it would be good to land this sooner to unblock progress on the [lexer refactoring](https://github.com/rust-lang/rust/pull/59706).
Fixes a part of https://github.com/rust-lang/rust/issues/43081 (literal tokens that are passed to proc macros are always precise, including hexadecimal numbers, strings with their original escaping, etc)
Fixes a part of https://github.com/rust-lang/rust/issues/60495 (everything except for proc macro API doesn't need escaping anymore)
This also allows to eliminate a certain hack from the lexer (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/pretty-printing.20comments/near/165005357).
bors [Sun, 12 May 2019 06:24:10 +0000 (06:24 +0000)]
Auto merge of #60396 - cuviper:ordered-retain, r=scottmcm
Document the order of {Vec,VecDeque,String}::retain
It's natural for `retain` to work in order from beginning to end, but
this wasn't actually documented to be the case. If we actually promise
this, then the caller can do useful things like track the index of each
element being tested, as [discussed in the forum][1]. This is now
documented for `Vec`, `VecDeque`, and `String`.
`HashMap` and `HashSet` also have `retain`, and the `hashbrown`
implementation does happen to use a plain `iter()` order too, but it's
not certain that this should always be the case for these types.
bors [Sat, 11 May 2019 19:13:12 +0000 (19:13 +0000)]
Auto merge of #60318 - jethrogb:jb/try-from-slice-to-infallible, r=sfackler
impl From<Infallible> for TryFromSliceError
I believe this was missed when TryFrom was stabilized. I think `TryFromSliceError` and `TryFromIntError` are the only two `TryFrom` error types that appear in `std`. I think trait implementations have to be insta-stable, but I'm not sure.
bors [Fri, 10 May 2019 19:56:15 +0000 (19:56 +0000)]
Auto merge of #60708 - Centril:rollup-j5smdo0, r=Centril
Rollup of 6 pull requests
Successful merges:
- #60529 (RFC 2008: Uninhabitedness fixes for enum variants and tests)
- #60620 (Fix a couple of FIXMEs in ext::tt::transcribe)
- #60659 (Tweak `Symbol` and `InternedString`)
- #60692 (Extend #60676 test for nested mut patterns.)
- #60697 (add regression test for #60629)
- #60701 (Update mailmap for mati865)
Rollup merge of #60697 - hellow554:fix_60629, r=michaelwoerister
add regression test for #60629
This bug was fixed, but I don't know which one. (I think it even doesn't matter at all).
Added a regression test.
```
op@OP ~/m/r/s/t/incremental> rustc --version
rustc 1.35.0-nightly (acd8dd6a5 2019-04-05)
op@OP ~/m/r/s/t/incremental> rustc -C incremental= --cfg rpass1 issue-60629.rs
warning: struct is never constructed: `A`
--> issue-60629.rs:3:1
|
3 | struct A;
| ^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
op@OP ~/m/r/s/t/incremental> rustc -C incremental= --cfg rpass2 issue-60629.rs
error: internal compiler error: src/librustc/ty/query/plumbing.rs:1195: Cannot force dep node: coherent_trait(core[c27c]::ops[0]::drop[0]::Drop[0])
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:635:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.35.0-nightly (acd8dd6a5 2019-04-05) running on x86_64-unknown-linux-gnu
note: compiler flags: -C incremental
```
with latest nightly it does not crash anymore, so nothing more to do.
Fixes #60629
(accidentally removed the remote branch on github, therefore GH closed the other PR.)
Rollup merge of #60620 - mark-i-m:transcribe-2, r=petrochenkov
Fix a couple of FIXMEs in ext::tt::transcribe
_Blocked on #60618_
A crater run would be nice to make sure my understanding is correct. A quick google search seems to indicate these are extremely rare errors if they are possible (which I don't believe they are).
r? @petrochenkov
cc #2887 (there is only one FIXME left and it is hygiene-related)
Rollup merge of #60529 - davidtwco:rfc-2008-uninhabited, r=petrochenkov
RFC 2008: Uninhabitedness fixes for enum variants and tests
Part of #44109.
At the request of @Centril, this PR adds tests asserting that uninhabited non-exhaustive types are considered inhabited in extern crates. In adding these tests, I fixed an oversight in the implementation of RFC 2008 on enum variants that resulted in non-exhaustive enum variants being considered uninhabited in extern crates.
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
bors [Fri, 10 May 2019 07:02:38 +0000 (07:02 +0000)]
Auto merge of #60585 - sunfishcode:wasm32-wasi, r=alexcrichton
Omit the vendor component in the WASI triple
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
bors [Fri, 10 May 2019 00:51:14 +0000 (00:51 +0000)]
Auto merge of #60683 - Centril:rollup-p05qh5d, r=Centril
Rollup of 8 pull requests
Successful merges:
- #59348 (Clean up and add tests for slice drop shims)
- #60188 (Identify when a stmt could have been parsed as an expr)
- #60234 (std: Derive `Default` for `io::Cursor`)
- #60618 (Comment ext::tt::transcribe)
- #60648 (Skip codegen for one UI test with long file path)
- #60671 (remove unneeded `extern crate`s from build tools)
- #60675 (Remove the old await! macro)
- #60676 (Fix async desugaring providing wrong input to procedural macros.)
Rollup merge of #60676 - davidtwco:issue-60674, r=cramertj
Fix async desugaring providing wrong input to procedural macros.
Fixes #60674.
This PR fixes a minor oversight introduced by #60535 where unused `mut` binding modes were removed from the arguments to an `async fn` (as they were added to the statement that we insert into the closure body). However, this meant that the input to procedural macros was incorrect. This removes that and instead fixes the `unused_mut` error that it avoided.
Rollup merge of #60648 - petrochenkov:shorten2, r=Dylan-DPC
Skip codegen for one UI test with long file path
The path to this test is so long that object files produced by it hit some path length limit on Windows and linker cannot find them.
The workaround here is to skip codegen and avoid producing object files, this test doesn't need them anyway.
Rollup merge of #60188 - estebank:recover-block, r=varkor
Identify when a stmt could have been parsed as an expr
There are some expressions that can be parsed as a statement without
a trailing semicolon depending on the context, which can lead to
confusing errors due to the same looking code being accepted in some
places and not others. Identify these cases and suggest enclosing in
parenthesis making the parse non-ambiguous without changing the
accepted grammar.