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 )
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
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
This PR reverts #29543 and instead implements proper support for "=*m" and "+*m" indirect output operands. This provides a framework on top of which support for plain memory operands ("m", "=m" and "+m") can be implemented.
This also fixes the liveness analysis pass not handling read/write operands correctly.
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
This PR for #30299 adds the name of the type where the field is missing.
The span that's used for the error seems correct. What may be confusing is when the initializer with the missing field contains other intializers. These are then included in the span. For example, consider the following listing.
struct A {
a1: i32,
a2: B,
}
struct B {
b1: i32,
b2: i32
}
fn main() {
let x = A {
a2: B {
b1: 1,
b2: 1
},
};
}
It will display the following code snippet along with the message that field `a2` is missing:
let x = A {
a2: B {
b1: 1,
b2: 1
},
};
By adding the name of the type it's clearer where the field is missing.
r? @nrc
Since PR #30294 unintentionally fixed issue #30159, it can cause breakage for a different reason than I originally stated in the PR (see #30159, I characterized the issue precisely there).
This commit limits the scope of the breakage to what I originally stated in the PR by "unfixing" the backwards incompatible part of #30159.
I think fixing #30159 has enough potential for breakage to warrant a crater run. If you disagree, I can cancel this PR, leaving it fixed.
Fixes#29844
I would prefer to
(a) make some performance measurements
(b) use the unification table in a few more places
before committing further, but this is probably good enough for beta.
r? @nikomatsakis
This fixes a bug in which the visibility of a use declaration defining a name in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace). For example,
```rust
fn f() {}
pub mod bar {}
mod foo {
use f; // This import should not be visible outside `foo`,
pub use bar as f; // but it visible outside of `foo` because of this import.
}
fn main() { foo::f(); }
```
As the example demonstrates, this is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by correcting visibility modifiers.
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
