Rollup merge of #65026 - petrochenkov:ice1, r=eddyb
metadata: Some crate loading cleanup
So, my goal was to fix caching of loaded crates which is broken and causes ICEs like #56935 or #64450.
While investigating I found that the code is pretty messy and likes to confuse various things that look similar but are actually different.
This PR does some initial cleanup in that area, I hope to get to the caching itself a bit later.
Rollup merge of #64817 - csmoe:closure, r=nikomatsakis
Replace ClosureSubsts with SubstsRef
Addresses https://github.com/rust-lang/rust/issues/42340 part 3
https://github.com/rust-lang/rust/pull/59312 might benefit from this clean up.
r? @nikomatsakis
Tyler Mandry [Thu, 3 Oct 2019 23:25:39 +0000 (16:25 -0700)]
Rollup merge of #64690 - petrochenkov:mixed, r=dtolnay
proc_macro API: Expose `macro_rules` hygiene
Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.
To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until https://github.com/rust-lang/rust/pull/64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.
I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.
This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.
This API addition opens the way to stabilizing proc macros in expression positions (https://github.com/rust-lang/rust/issues/54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)
Tyler Mandry [Thu, 3 Oct 2019 23:25:37 +0000 (16:25 -0700)]
Rollup merge of #64675 - Centril:deprecate-plugin, r=oli-obk
Deprecate `#![plugin]` & `#[plugin_registrar]`
This PR deprecates `#![plugin]` and `#[plugin_registrar]`.
~A removal deadline is set: 1.44.0. This will be in 9 months from now and should give everyone who is still relying on the feature ample time to rid themselves of this dependency.~
It was only used for retreiving edition, which was a bug.
In case of dual proc macros the edition should be taken from the target crate version, like any other metadata.
Allocate a new diagnostic for defaulted type parameters cannot use `Self`
(Without this commit, you still get an error (a very similar one, at
that), but it complains about use of forward declaration, which is
confusing since people do not necessarily think of `Self` as being
declared at all.)
bors [Thu, 3 Oct 2019 02:08:53 +0000 (02:08 +0000)]
Auto merge of #65038 - Centril:rollup-m83dpfh, r=Centril
Rollup of 7 pull requests
Successful merges:
- #63678 (Improve HRTB error span when -Zno-leak-check is used)
- #64931 (Reword E0392 slightly)
- #64959 (syntax: improve parameter without type suggestions)
- #64975 (Implement Clone::clone_from for LinkedList)
- #64993 (BacktraceStatus: add Eq impl)
- #64998 (Filter out RLS output directories on tidy runs)
- #65010 (Compare `primary` with maximum of `children`s' line num instead of dropping it)
Rollup merge of #64993 - mathstuf:backtrace-status-eq, r=withoutboats
BacktraceStatus: add Eq impl
See discussion on #53487.
---
Is adding `Copy` too ambitious? It's a "status", so I don't forsee any non-POD data that might go in there, but it would restrict future variants more than `Eq` does.
Rollup merge of #64975 - crgl:clone-from-linked-list, r=bluss
Implement Clone::clone_from for LinkedList
See #28481. This represents a substantial speedup when the list sizes are comparable, and shouldn't ever be significantly worse. Technically split_off is doing an unnecessary search, but the code is hopefully cleaner as a result. I'm happy to rework anything that needs to be changed as well!
Rollup merge of #64959 - davidtwco:issue-64252-self-type-help, r=Centril,estebank
syntax: improve parameter without type suggestions
Fixes #64252.
This PR improves the suggestions provided when function parameters
do not have types:
- A new suggestion is added for arbitrary self types, which suggests
adding `self: ` before the type.
- Existing suggestions are now provided when a `<` is found where a `:`
was expected (previously only `,` and `)` or trait items), this gives
suggestions in the case where the unnamed parameter type is generic
in a free function.
- The suggestion that a type name be provided (e.g. `fn foo(HashMap<u32>)`
-> `fn foo(HashMap: TypeName<u32>)`) will no longer occur when a `<` was
found instead of `:`.
- The ident will not be used for recovery when a `<` was found instead
of `:`.
Rollup merge of #63678 - Aaron1011:fix/hrtb-leak, r=nikomatsakis
Improve HRTB error span when -Zno-leak-check is used
As described in #57374, NLL currently produces unhelpful higher-ranked
trait bound (HRTB) errors when '-Zno-leak-check' is enabled.
This PR tackles one half of this issue - making the error message point
at the proper span. The error message itself is still the very generic
"higher-ranked subtype error", but this can be improved in a follow-up
PR.
The root cause of the bad spans lies in how NLL attempts to compute the
'blamed' region, for which it will retrieve a span for.
Consider the following code, which (correctly) does not compile:
```rust
let my_val: u8 = 25;
let a: &u8 = &my_val;
let b = a;
let c = b;
let d: &'static u8 = c;
```
This will cause NLL to generate the following subtype constraints:
d :< c
c :< b
b <: a
Since normal Rust lifetimes are covariant, this results in the following
region constraints (I'm using 'd to denote the lifetime of 'd',
'c to denote the lifetime of 'c, etc.):
'c: 'd
'b: 'c
'a: 'b
From this, we can derive that 'a: 'd holds, which implies that 'a: 'static
must hold. However, this is not the case, since 'a refers to 'my_val',
which does not outlive the current function.
When NLL attempts to infer regions for this code, it will see that the
region 'a has grown 'too large' - it will be inferred to outlive
'static, despite the fact that is not declared as outliving 'static
We can find the region responsible, 'd, by starting at the *end* of
the 'constraint chain' we generated above. This works because for normal
(non-higher-ranked) lifetimes, we generally build up a 'chain' of
lifetime constraints *away* from the original variable/lifetime.
That is, our original lifetime 'a is required to outlive progressively
more regions. If it ends up living for too long, we can look at the
'end' of this chain to determine the 'most recent' usage that caused
the lifetime to grow too large.
However, this logic does not work correctly when higher-ranked trait
bounds (HRTBs) come into play. This is because HRTBs have
*contravariance* with respect to their bound regions. For example,
this code snippet compiles:
```rust
let a: for<'a> fn(&'a ()) = |_| {};
let b: fn(&'static ()) = a;
```
Here, we require that 'a' is a subtype of 'b'. Because of
contravariance, we end up with the region constraint 'static: 'a,
*not* 'a: 'static
This means that our 'constraint chains' grow in the opposite direction
of 'normal lifetime' constraint chains. As we introduce subtypes, our
lifetime ends up being outlived by other lifetimes, rather than
outliving other lifetimes. Therefore, starting at the end of the
'constraint chain' will cause us to 'blame' a lifetime close to the original
definition of a variable, instead of close to where the bad lifetime
constraint is introduced.
This PR improves how we select the region to blame for 'too large'
universal lifetimes, when bound lifetimes are involved. If the region
we're checking is a 'placeholder' region (e.g. the region 'a' in
for<'a>, or the implicit region in fn(&())), we start traversing the
constraint chain from the beginning, rather than the end.
There are two (maybe more) different ways we generate region constraints for NLL:
requirements generated from trait queries, and requirements generated
from MIR subtype constraints. While the former always use explicit
placeholder regions, the latter is more tricky. In order to implement
contravariance for HRTBs, TypeRelating replaces placeholder regions with
existential regions. This requires us to keep track of whether or not an
existential region was originally a placeholder region. When we look for
a region to blame, we check if our starting region is either a
placeholder region or is an existential region created from a
placeholder region. If so, we start iterating from the beginning of the
constraint chain, rather than the end.
bors [Wed, 2 Oct 2019 18:28:11 +0000 (18:28 +0000)]
Auto merge of #65009 - Centril:rollup-06g05xj, r=Centril
Rollup of 13 pull requests
Successful merges:
- #64581 (Fix unreachable_code warnings for try{} block ok-wrapped expressions)
- #64850 (Remove inlines from DepNode code)
- #64914 (regression test for 64453 borrow check error.)
- #64922 (Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions)
- #64948 (Improve sidebar styling to make its integration easier)
- #64961 (Make comment about dummy type a bit more clear)
- #64967 (Don't mark borrows of zero-sized arrays as indirectly mutable)
- #64973 (Fix typo while setting `compile-flags` in test)
- #64980 (Enable support for `IndirectlyMutableLocals` in `rustc_peek` )
- #64989 (Fix ICE #64964)
- #64991 ([const-prop] Correctly handle locals that can't be propagated)
- #64995 (Remove rustdoc warning)
- #64997 (rustc book: nitpick SLP vectorization)
Rollup merge of #64995 - GuillaumeGomez:libtest-rustdoc-warning, r=Mark-Simulacrum
Remove rustdoc warning
Removes this warning:
```bash
Finished release [optimized] target(s) in 2.62s
Documenting core v0.0.0 (/home/imperio/rust/rust/src/libcore)
Finished release [optimized] target(s) in 15.23s
Documenting std v0.0.0 (/home/imperio/rust/rust/src/libstd)
Finished release [optimized] target(s) in 17.30s
Documenting proc_macro v0.0.0 (/home/imperio/rust/rust/src/libproc_macro)
Finished release [optimized] target(s) in 2.36s
Documenting test v0.0.0 (/home/imperio/rust/rust/src/libtest)
warning: `[0]` cannot be resolved, ignoring it...
--> src/libtest/lib.rs:1112:41
|
1112 | /// supplied channel. Requires argv[0] to exist and point to the binary
| ^ cannot be resolved, ignoring
|
= note: `#[warn(intra_doc_link_resolution_failure)]` on by default
= help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`
Finished release [optimized] target(s) in 1.64s
Build completed successfully in 0:02:07
```
Rollup merge of #64991 - wesleywiser:fix_too_eager_const_prop, r=oli-obk
[const-prop] Correctly handle locals that can't be propagated
`const_prop()` now handles writing the Rvalue into the Place in the
stack frame for us. So if we're not supposed to propagate that value,
we need to clear it.
Rollup merge of #64980 - ecstatic-morse:better-rustc-peek, r=oli-obk
Enable support for `IndirectlyMutableLocals` in `rustc_peek`
This PR allows `rustc_peek` tests to be written for the `IndirectlyMutableLocals` analysis implemented in #64470. See any of the tests in [`test/ui/mir-dataflow`](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir-dataflow/inits-1.rs) for an example.
Included in this PR is a major rewrite of the `rustc_peek` module. This was motivated by the differences between the `IndirectlyMutableLocals` analysis and the initialized places ones.
To properly test `IndirectlyMutableLocals`, we must pass locals by-value to `rustc_peek`, since any local that is not `Freeze` will be marked as indirectly mutable as soon as a reference to it is taken. Unfortunately, `UnsafeCell` is not `Copy`, so we can only do one `rustc_peek` on each value with interior mutability inside a test. I'm not sure how to deal with this restriction; perhaps I need to special case borrows preceding a call to `rustc_peek` in the analysis itself?
`rustc_peek` also assumed that the analysis was done on move paths and that its transfer function only needed to be applied at assignment statements. This PR removes both of those restrictions by adding a trait, `RustcPeekAt`, that controls how the peeked at `Place` maps to the current dataflow state and using a dataflow cursor to retrieve the state itself.
Finally, this PR adds a test which demonstrates some unsoundness in the `IndirectlyMutableLocals` analysis by converting a reference to a `Freeze` field to a reference to a `!Freeze` field by offsetting a pointer (or in this case transmuting a pointer to a ZST field with the same address as a `!Freeze` field). This does not represent a hole in the language proper, since this analysis is only used to validate `const` bodies, in which the unsound code will only compile with `-Zunleash-the-miri-inside-of-you`. Nevertheless, this should get fixed.
projects / rust.git / log