associated machinery. Future such attempts should go through lints
anyhow.
There is a fair amount of fallout in the compile-fail tests, as WF
checking now occurs earlier in the process.
previously the error was erased and a `non-const path` error was emitted at the location of the field access instead of at the overflow location (as can be seen in the playground: http://is.gd/EuAF5F )
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
Still will not translate references to items like `X` or `Y::V` where
```
struct X;
enum Y { V }
```
but I must go work on university things so I’m PRing what I have.
r? @nikomatsakis
The Rustonomicon's Lifetimes chapter uses the idiom "big ask", which is obscure compared to "tall order" (check [Google ngrams](https://books.google.com/ngrams/graph?content=big+ask%2C+tall+order&year_start=1800)). Also, it's easily mistaken for a typo; either "a big task" or "a big thing to ask" could plausibly work there.
r? @steveklabnik
…entation clearer
I could not use colors as suggested for #29854 because Github doesn't support these in markdown, however this solution may be better for color-blind readers.
This fixes a bug in which unused imports can get wrongly marked as used when checking for unused qualifications in `resolve_path` (issue #30078), and it removes unused imports that were previously undetected because of the bug.
The Rustonomicon's Lifetimes chapter uses the idiom "big ask", which is obscure compared to "tall order" (check Google ngrams). Also, it's easily mistaken for a typo; either "a big task" or "a big thing to ask" could plausibly work there.
Ensure borrows of fn/closure params do not outlive invocations.
Does this by adding a new CallSiteScope to the region (or rather code extent) hierarchy, which outlives even the ParameterScope (which in turn outlives the DestructionScope of a fn/closure's body).
Fix#29793
r? @nikomatsakis
Currently, a coherence error based on overlapping impls simply mentions
the trait, and points to the two conflicting impls:
```
error: conflicting implementations for trait `Foo`
```
With this commit, the error will include all input types to the
trait (including the `Self` type) after unification between the
overlapping impls. In other words, the error message will provide
feedback with full type details, like:
```
error: conflicting implementations of trait `Foo<u32>` for type `u8`:
```
When the `Self` type for the two impls unify to an inference variable,
it is elided in the output, since "for type `_`" is just noise in that
case.
Closes#23980
r? @nikomatsakis
Currently, a coherence error based on overlapping impls simply mentions
the trait, and points to the two conflicting impls:
```
error: conflicting implementations for trait `Foo`
```
With this commit, the error will include all input types to the
trait (including the `Self` type) after unification between the
overlapping impls. In other words, the error message will provide
feedback with full type details, like:
```
error: conflicting implementations of trait `Foo<u32>` for type `u8`:
```
When the `Self` type for the two impls unify to an inference variable,
it is elided in the output, since "for type `_`" is just noise in that
case.
Closes#23980
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
We can now handle name resolution errors and get past type checking (if we're a bit lucky). This is the first step towards doing code completion for partial programs (we need error recovery in the parser and early access to save-analysis).
This reduces iteration time (`make rustc-stage1`) for moved syntax extensions from 11 minutes to 3 minutes on my machine.
Because of the signature change, this is a [breaking-change] for people directly calling `expand_crate`. I think it is rare: from GitHub search, only case I found is [glassful](https://github.com/kmcallister/glassful).
Closes https://github.com/rust-lang/rust/issues/29935
The attributes `deprecated` and `rustc_deprecated` are completely independent in this implementation and it leads to some noticeable code duplication. Representing `deprecated` as
```
Stability {
level: Stable { since: "" },
feature: "",
depr: Some(Deprecation),
}
```
or, contrariwise, splitting rustc_deprecation from stability makes most of the duplication go away.
I can do this refactoring, but before doing it I must be sure, that further divergence of `deprecated` and `rustc_deprecated` is certainly not a goal.
cc @llogiq
