make lifetimes that only appear in return type early-bound
This is the full and proper fix for #32330. This also makes some effort to give a nice error message (as evidenced by the `ui` test), sending users over to the tracking issue for a fuller explanation and offering a `--explain` message in some cases.
This needs a crater run before we land.
r? @arielb1
This is the full and proper fix for #32330. This also makes some effort
to give a nice error message (as evidenced by the `ui` test), sending
users over to the tracking issue for a full explanation.
Add warning for () to ! switch
With feature(never_type) enabled diverging type variables will default to `!` instead of `()`. This can cause breakages where a trait is resolved on such a type.
This PR emits a future-compatibility warning when it sees this happen.
rustdoc: fix doctests with non-feature crate attrs
Fixes#38129.
The book says that any top-level crate attributes at the beginning of a doctest are moved outside the generated `fn main`, but it was only checking for `#![feature`, not `#![`.
These attributes previously caused warnings but were then ignored, so in theory this could change the behavior of doctests in the wild.
Implement kind="static-nobundle" (RFC 1717)
This implements the "static-nobundle" library kind (last item from #37403).
Rustc handles "static-nobundle" libs very similarly to dylibs, except that on Windows, uses of their symbols do not get marked with "dllimport". Which is the whole point of this feature.
Previously, the note/message for the source of a lint being the command
line unconditionally named the individual lint, even if the actual
command specified a lint group (e.g., `-D warnings`); here, we take note
of the actual command options so we can be more specific.
This remains in the matter of #36846.
Warning or error messages set via a lint group attribute
(e.g. `#[deny(warnings)]`) should still make it clear which individual
lint (by name) was triggered, similarly to how we include "on by
default" language for default lints. This—and, while we're here, the
existing "on by default" language—can be tucked into a note rather than
cluttering the main error message. This occasions the slightest of
refactorings (we now have to get the diagnostic-builder with the main
message first, before matching on the lint source).
This is in the matter of #36846.
Miscellaneous refactors around how lints and typeck interact
This is preparation for making incr. comp. skip typeck. The main gist of is trying to rationalize the outputs from typeck that are not part of tables:
- one bit of output is the `used_trait_imports` set, which becomes something we track for dependencies
- the other big of output are various lints; we used to store these into a table on sess, but this work stores them into the`TypeckTables`, and then makes the lint pass consult that
- I think it probably makes sense to handle errors similarly, eventually, but that's not necessary now
r? @eddyb
Fixes#39495
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
The previous way was not friendly to incremental compilation. The new
plan is to compute, for each body, a set of trait imports used in that
body (slightly subtle: for a closure, we assign the trait imports to the
enclosing fn). Then we walk all bodies and union these sets. The reason
we do this is that we can save the individual sets in the incremental
state, and then recompute only those sets that are needed. Before we
were planning to save only the final union, but in that case if some
components are invalidated we have to recompute *all* of them since we
don't have enough information to "partly" invalidate a result.
In truth, this set probably ought to be part of the `TypeckTables`;
however, I opted not to do that because I don't want to have to
save/restore the entire tables in the incremental state yet (since it
contains a lot of `NodeId` references, and removing those is a
significant refactoring).
Privatize constructors of tuple structs with private fields
This PR implements the strictest version of such "privatization" - it just sets visibilities for struct constructors, this affects everything including imports.
```
visibility(struct_ctor) = min(visibility(struct), visibility(field_1), ..., visibility(field_N))
```
Needs crater run before proceeding.
Resolves https://github.com/rust-lang/rfcs/issues/902
r? @nikomatsakis
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
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
