As far as I can tell, multiple `--test-args` flags are ignored (only the first is respected), so if you specify a subdirectory, you won't also be able to filter using `--test-args`. If you don't specify a subdirectory, `--test-args` will continue working as usual, so this is strictly an improvement on the current state of affairs.
Rollup merge of #60444 - nikomatsakis:issue-60010-cycle-error-investigation, r=pnkfelix
forego caching for all participants in cycles, apart from root node
This is a targeted fix for #60010, which uncovered a pretty bad failure of our caching strategy in the face of coinductive cycles. The problem is explained in the comment in the PR on the new field, `in_cycle`, but I'll reproduce it here:
> Starts out as false -- if, during evaluation, we encounter a
> cycle, then we will set this flag to true for all participants
> in the cycle (apart from the "head" node). These participants
> will then forego caching their results. This is not the most
> efficient solution, but it addresses #60010. The problem we
> are trying to prevent:
>
> - If you have `A: AutoTrait` requires `B: AutoTrait` and `C: NonAutoTrait`
> - `B: AutoTrait` requires `A: AutoTrait` (coinductive cycle, ok)
> - `C: NonAutoTrait` requires `A: AutoTrait` (non-coinductive cycle, not ok)
>
> you don't want to cache that `B: AutoTrait` or `A: AutoTrait`
> is `EvaluatedToOk`; this is because they were only considered
> ok on the premise that if `A: AutoTrait` held, but we indeed
> encountered a problem (later on) with `A: AutoTrait. So we
> currently set a flag on the stack node for `B: AutoTrait` (as
> well as the second instance of `A: AutoTrait`) to supress
> caching.
>
> This is a simple, targeted fix. The correct fix requires
> deeper changes, but would permit more caching: we could
> basically defer caching until we have fully evaluated the
> tree, and then cache the entire tree at once.
I'm not sure what the impact of this fix will be in terms of existing crates or performance: we were accepting incorrect code before, so there will perhaps be some regressions, and we are now caching less.
As the comment above notes, we could do a lot better than this fix, but that would involve more invasive rewrites. I thought it best to start with something simple.
r? @pnkfelix -- but let's do crater/perf run
cc @arielb1
Rollup merge of #60443 - RalfJung:as_ptr, r=SimonSapin
as_ptr returns a read-only pointer
Add comments to `as_ptr` methods to warn that these are read-only pointers, and writing to them is UB.
[It was pointed out](https://internals.rust-lang.org/t/as-ptr-vs-as-mut-ptr/9940) that `CStr` does not even have an `as_mut_ptr`. I originally was going to add one, but there is no method at all that would mutate a `CStr`. Was that a deliberate choice or should I add an `as_mut_ptr` (similar to [what I did for `str`](https://github.com/rust-lang/rust/pull/58200))?
Rollup merge of #60130 - khuey:efficient_last, r=sfackler
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators
Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators.
I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so.
The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
bors [Tue, 14 May 2019 15:58:33 +0000 (15:58 +0000)]
Auto merge of #60787 - alexcrichton:error-type-id-destabilize-master, r=pietroalbini
Destabilize the `Error::type_id` function
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:
struct MyType;
impl Error for MyType {
fn type_id(&self) -> TypeId {
// Enable safe casting to `String` by accident.
TypeId::of::<String>()
}
}
This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the [security mailing list](https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70) as well as [the blog](https://blog.rust-lang.org/2019/05/13/Security-advisory.html)
This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
bors [Tue, 14 May 2019 03:09:46 +0000 (03:09 +0000)]
Auto merge of #60794 - Centril:rollup-vlguvns, r=Centril
Rollup of 5 pull requests
Successful merges:
- #60176 (Explain error when yielding a reference to a local variable)
- #60201 (coretest: Downgrade deny to warn)
- #60562 (Add #[doc(hidden)] attribute on compiler generated module.)
- #60710 (Use `delay_span_bug` for error cases when checking `AnonConst` parent)
- #60770 (add impl_trait_in_bindings to INCOMPLETE_FEATURES)
Rollup merge of #60201 - RalfJung:core-tests, r=alexcrichton
coretest: Downgrade deny to warn
The `deny` causes a build failure in https://github.com/RalfJung/miri-test-libstd. Since we use `-D warnings` for rustc builds, `warn` should be enough to lead to compile errors here, without impeding external builds.
Alex Crichton [Mon, 13 May 2019 15:14:02 +0000 (08:14 -0700)]
Destabilize the `Error::type_id` function
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:
struct MyType;
impl Error for MyType {
fn type_id(&self) -> TypeId {
// Enable safe casting to `String` by accident.
TypeId::of::<String>()
}
}
This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
security announcement will be shortly posted to the security mailing list as
well as the Rust Blog, and when those links are available they'll be filled in
for this PR as well.
This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
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...