This PR is a rebase of the original PR by @eddyb https://github.com/rust-lang/rust/pull/21836 with some unrebasable parts manually reapplied, feature gate added + type equality restriction added as described below.
This implementation is partial because the type equality restriction is applied to all type ascription expressions and not only those in lvalue contexts. Thus, all difficulties with detection of these contexts and translation of coercions having effect in runtime are avoided.
So, you can't write things with coercions like `let slice = &[1, 2, 3]: &[u8];`. It obviously makes type ascription less useful than it should be, but it's still much more useful than not having type ascription at all.
In particular, things like `let v = something.iter().collect(): Vec<_>;` and `let u = t.into(): U;` work as expected and I'm pretty happy with these improvements alone.
Part of https://github.com/rust-lang/rust/issues/23416
Make RFC 1214 warnings into errors, and rip out the "warn or err"
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.
r? @arielb1
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.
LLVM doesn't really support reusing the same module to emit more than
one file. One bug this causes is that the IR is invalidated by the stack
coloring pass when emitting the first file, and then the IR verifier
complains by the time we try to emit the second file. Also, we get
different binaries with --emit=asm,link than with just --emit=link. In
some cases leading to segfaults.
Unfortunately, it seems that at this point in time, the most sensible
option to circumvent this problem is to just clone the whole llvm module
for the asm output if we need both, asm and obj file output.
Fixes#24876Fixes#26235
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 )
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 )
LLVM doesn't really support reusing the same module to emit more than
one file. One bug this causes is that the IR is invalidated by the stack
coloring pass when emitting the first file, and then the IR verifier
complains by the time we try to emit the second file. Also, we get
different binaries with --emit=asm,link than with just --emit=link. In
some cases leading to segfaults.
Unfortunately, it seems that at this point in time, the most sensible
option to circumvent this problem is to just clone the whole llvm module
for the asm output if we need both, asm and obj file output.
Fixes#24876Fixes#26235
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
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
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
