| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Perform lifetime elision (more) syntactically, before type-checking.
The *initial* goal of this patch was to remove the (contextual) `&RegionScope` argument passed around `rustc_typeck::astconv` and allow converting arbitrary (syntactic) `hir::Ty` to (semantic) `Ty`.
I've tried to closely match the existing behavior while moving the logic to the earlier `resolve_lifetime` pass, and [the crater report](https://gist.github.com/eddyb/4ac5b8516f87c1bfa2de528ed2b7779a) suggests none of the changes broke real code, but I will try to list everything:
There are few cases in lifetime elision that could trip users up due to "hidden knowledge":
```rust
type StaticStr = &'static str; // hides 'static
trait WithLifetime<'a> {
type Output; // can hide 'a
}
// This worked because the type of the first argument contains
// 'static, although StaticStr doesn't even have parameters.
fn foo(x: StaticStr) -> &str { x }
// This worked because the compiler resolved the argument type
// to <T as WithLifetime<'a>>::Output which has the hidden 'a.
fn bar<'a, T: WithLifetime<'a>>(_: T::Output) -> &str { "baz" }
```
In the two examples above, elision wasn't using lifetimes that were in the source, not even *needed* by paths in the source, but rather *happened* to be part of the semantic representation of the types.
To me, this suggests they should have never worked through elision (and they don't with this PR).
Next we have an actual rule with a strange result, that is, the return type here elides to `&'x str`:
```rust
impl<'a, 'b> Trait for Foo<'a, 'b> {
fn method<'x, 'y>(self: &'x Foo<'a, 'b>, _: Bar<'y>) -> &str {
&self.name
}
}
```
All 3 of `'a`, `'b` and `'y` are being ignored, because the `&self` elision rule only cares that the first argument is "`self` by reference". Due implementation considerations (elision running before typeck), I've limited it in this PR to a reference to a primitive/`struct`/`enum`/`union`, but not other types, but I am doing another crater run to assess the impact of limiting it to literally `&self` and `self: &Self` (they're identical in HIR).
It's probably ideal to keep an "implicit `Self` for `self`" type around and *only* apply the rule to `&self` itself, but that would result in more bikeshed, and #21400 suggests some people expect otherwise.
Another decent option is treating `self: X, ... -> Y` like `X -> Y` (one unique lifetime in `X` used for `Y`).
The remaining changes have to do with "object lifetime defaults" (see RFCs [599](https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md) and [1156](https://github.com/rust-lang/rfcs/blob/master/text/1156-adjust-default-object-bounds.md)):
```rust
trait Trait {}
struct Ref2<'a, 'b, T: 'a+'b>(&'a T, &'b T);
// These apply specifically within a (fn) body,
// which allows type and lifetime inference:
fn main() {
// Used to be &'a mut (Trait+'a) - where 'a is one
// inference variable - &'a mut (Trait+'b) in this PR.
let _: &mut Trait;
// Used to be an ambiguity error, but in this PR it's
// Ref2<'a, 'b, Trait+'c> (3 inference variables).
let _: Ref2<Trait>;
}
```
What's happening here is that inference variables are created on the fly by typeck whenever a lifetime has no resolution attached to it - while it would be possible to alter the implementation to reuse inference variables based on decisions made early by `resolve_lifetime`, not doing that is more flexible and works better - it can compile all testcases from #38624 by not ending up with `&'static mut (Trait+'static)`.
The ambiguity specifically cannot be an early error, because this is only the "default" (typeck can still pick something better based on the definition of `Trait` and whether it has any lifetime bounds), and having an error at all doesn't help anyone, as we can perfectly infer an appropriate lifetime inside the `fn` body.
**TODO**: write tests for the user-visible changes.
cc @nikomatsakis @arielb1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
move `cast_kinds` into `TypeckTables` where it belongs
r? @eddyb
|
|
doc comment typo fix
|
|
Hide uninhabitedness checks behind feature gate
This reverts the fix to match exhaustiveness checking so that it can be discussed. The new code is now hidden behind the `never_type` feature gate.
|
|
rustc: Remove all "consider using an explicit lifetime parameter" suggestions
These give so many incorrect suggestions that having them is
detrimental to the user experience. The compiler should not be
suggesting changes to the code that are wrong - it is infuriating: not
only is the compiler telling you that _you don't understand_ borrowing,
_the compiler itself_ appears to not understand borrowing. It does not
inspire confidence.
r? @nikomatsakis
|
|
|
|
incr.comp.: Make cross-crate tracking for incr. comp. opt-in.
The current implementation of cross-crate dependency tracking can cause quite long compile times and high memory usage for some crates (see #39208 for example). This PR therefore makes that part of dependency tracking optional. Incremental compilation still works, it will only have very coarse dep-tracking for upstream crates.
r? @nikomatsakis
|
|
Point to immutable arg/fields when trying to use as &mut
Present the following output when trying to access an immutable borrow's
field as mutable:
```
error[E0389]: cannot borrow data mutably in a `&` reference
--> $DIR/issue-38147-1.rs:27:9
|
26 | fn f(&self) {
| ----- use `&mut self` here to make mutable
27 | f.s.push('x');
| ^^^ assignment into an immutable reference
```
And the following when trying to access an immutable struct field as mutable:
```
error: cannot borrow immutable borrowed content `*self.s` as mutable
--> $DIR/issue-38147-3.rs:17:9
|
12 | s: &'a String
| ------------- use `&'a mut String` here to make mutable
...|
16 | fn f(&self) {
| ----- use `&mut self` here to make mutable
17 | self.s.push('x');
| ^^^^^^ cannot borrow as mutable
```
Fixes #38147.
|
|
These give so many incorrect suggestions that having them is
detrimental to the user experience. The compiler should not be
suggesting changes to the code that are wrong - it is infuriating: not
only is the compiler telling you that _you don't understand_ borrowing,
_the compiler itself_ appears to not understand borrowing. It does not
inspire confidence.
|
|
Point to immutable borrow arguments and fields when trying to use them as
mutable borrows. Add label to primary span on "cannot borrow as mutable"
errors.
Present the following output when trying to access an immutable borrow's
field as mutable:
```
error[E0389]: cannot borrow data mutably in a `&` reference
--> $DIR/issue-38147-1.rs:27:9
|
26 | fn f(&self) {
| ----- use `&mut self` here to make mutable
27 | f.s.push('x');
| ^^^ assignment into an immutable reference
```
And the following when trying to access an immutable struct field as mutable:
```
error: cannot borrow immutable borrowed content `*self.s` as mutable
--> $DIR/issue-38147-3.rs:17:9
|
12 | s: &'a String
| ------------- use `&'a mut String` here to make mutable
...|
16 | fn f(&self) {
| ----- use `&mut self` here to make mutable
17 | self.s.push('x');
| ^^^^^^ cannot borrow as mutable
```
|
|
|
|
End temporary lifetimes being extended by `let X: &_` hints
cc #39283
r? @nikomatsakis
|
|
Rename tcx.map to the far more descriptive tcx.hir.
Also a bit more renaming because `ast_map` and `'ast` were still used with HIR.
Main motivation is to "free up" `tcx.map`, or rather, `tcx.maps`, to consolidate `ty::maps` there.
r? @nikomatsakis
|
|
Add a distinct error code and description for "main function has wron…
…g type"
|
|
|
|
|
|
|
|
|
|
Remove Reflect
PR for removing the `Reflect` trait. Opened so that a crater run can be done for testing the impact: https://github.com/rust-lang/rust/issues/27749#issuecomment-272665163
Fixes #27749
|
|
|
|
|
|
|
|
doc comment rewording
|
|
|
|
exclusive range patterns
adds `..` patterns to the language under a feature gate (`exclusive_range_pattern`).
This allows turning
``` rust
match i {
0...9 => {},
10...19 => {},
20...29 => {},
_ => {}
}
```
into
``` rust
match i {
0..10 => {},
10..20 => {},
20..30 => {},
_ => {}
}
```
|
|
Fixes #36082.
|
|
|
|
* Remove the Reflect trait
* Remove the "reflect" lang feature
|
|
|
|
|
|
better comment wording
|
|
r=arielb1
Change unreachable pattern ICEs to warnings
Allow code with unreachable `?` and `for` patterns to compile.
Add some tests.
|
|
|
|
|
|
|
|
|
