Permit -> _ return types for improved diagnostics

[varkor]

Consider (the invalid Rust code containing) a function that returns a value, but has no return type:

fn foo() {
    0u8
}

fn main() {
    let _: u8 = foo();
}

Currently, the compiler produces these errors:

error[E0308]: mismatched types
 --> src/main.rs:2:5
  |
1 | fn foo() {
  |          - help: try adding a return type: `-> u8`
2 |     0u8
  |     ^^^ expected (), found u8
  |
  = note: expected type `()`
             found type `u8`

error[E0308]: mismatched types
 --> src/main.rs:6:17
  |
6 |     let _: u8 = foo();
  |                 ^^^^^ expected u8, found ()
  |
  = note: expected type `u8`
             found type `()`

error: aborting due to 2 previous errors

In theory, the only problem is the missing return type, which, if provided, would cause the code to compile successfully.

The compiler knows what the return type should be here, and could potentially interpret the rest of the program as if the correct return type were given.

This issue proposes giving special treatment in the compiler for diagnostics only (note that this is not a language change) to the syntax -> _ for return types. This would report a normal error for a missing return type (no extra code would compile after this change), but would otherwise treat the function as having the missing return type. A machine-applicable suggestion would be provided to replace _ with the correct return type.

For example:

fn foo() -> _ {
    0u8
}

fn main() {
    let _: u8 = foo();
}

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/main.rs:1:13
  |
1 | fn foo() -> _ {
  |             ^ not allowed in type signatures
  |             - help: replace `_` with the correct return type: `u8`

[varkor]

This change would potentially set precedent for treating specific invalid/incomplete code specially in ways that are not reflected in valid code. In other words:

eddyb: we need to write up something about "guaranteed-error/diagnostic-only" "features", where the compiler does things it shouldn't do in strict terms of the Rust language, knowing it will error anyway, so any power the user gets is only in diagnostics, not in compiled code

This was originally proposed by @eddyb on Discord.

Relevant conversation:

eddyb: if you can convince people to make -> _ a compiler error that contains the type to put in there and provides it to callers (NB dependency cycles disallowed), I'll do it
varkor: I would have thought that -> _ could be given a type-inference based diagnostic approach right now, without an RFC or anything
varkor: it seems like a reasonable diagnostic improvement
eddyb: well, I want someone to confirm that :P

[varkor]

As this potentially sets precedent for diagnostic-motivated behaviour changes, it seems prudent to check that there aren't any concerns with doing this.

@rfcbot merge

[rfcbot]

Team member @varkor has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Zoxc
• @cramertj
• @eddyb
• @estebank
• @michaelwoerister
• @nagisa
• @nikomatsakis
• @oli-obk
• @petrochenkov
• @pnkfelix
• @varkor

Concerns:

• unneeded resolved by Permit -> _ return types for improved diagnostics #56132 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[eddyb]

Note that the implementation difficulty of this should be negligible, becuase we alrrady have on-demand queries, and we can switch between "check body against signature" and "get signature from body" trivially.

[scottmcm]

@rfcbot reviewed Oops, not my team 😆

I support this precedent, and think it obviates things like rust-lang/rfcs#2479

[petrochenkov]

Why is -> _ necessary in fn foo() -> _ { 0u8 }?
We can give exactly the same machine-applicable suggestion for fn foo() { 0u8 } without requiring typing extra characters.

[oli-obk]

The difference is that calls to the function would also know about the return type and not produce additional fallout. Basically return type inference like impl Trait, but transparent and only if an error was reported.

[estebank]

@rfcbot concern unneeded

An alternative would be to carry optional inferred type information on fn (and potentially all other) blocks. This way, if we present the above suggestion to change the return type to u8, we could, for the presented above code display something along the lines of:

error[E0308]: mismatched types
 --> src/main.rs:2:5
  |
1 | fn foo() {
  |          - help: try adding a return type: `-> u8`
2 |     0u8
  |     ^^^ expected return type (), found u8
...
6 |     let _: u8 = foo();
  |                 ----- expected u8 here as well
  |
  = note: expected type `()`
             found type `u8`

or just completely elide the error in line 6 by checking against both the resolved type (() here) and the suggested type (u8) if either match, do not emit that diagnostic. We already do something along these lines on blocks that have either parse or type errors, by marking them as TyErr and not emitting mismatched types errors that involve TyErr (as they have already being emitted in the source of the problem).

[leonardo-m]

I think in the Haskell world for something like this they invent a pretty name (something like Return Type Holes) and write a paper on it.

[eddyb]

@estebank That's not actionable because it breaks with cycles (think recursive function) - and we don't want to add recovery from dependency cycles.

The way it works with -> _ is that it's a switch for flipping a dependency edge in the compiler.

[estebank]

Couldn't this (changing -> () to -> _) be done implicitly by performing that change once the suggestion is emitted?

[eddyb]

@estebank No, that sort of side-effect is incompatible with the incremental dataflow ("query") model.

[Centril]

@scottmcm

I support this precedent, and think it obviates things like rust-lang/rfcs#2479

Obviously I disagree that it obviates that change; this will still error, not letting you finish cargo check nor cargo test so the experience is not the same.

That said I fully support this change.

[FrankSD]

Is this issue already taken? Please confirm I would like to take this on

[varkor]

@FrankSD: it's not, but you'll want to wait until the FCP has (started and) finished before working on this, to avoid wasting time if the FCP does not pass.

[estebank]

I have philosophical disagreements with this idea, as I'd prefer the compiler to not need this (as I see it) kludge and instead provide better diagnostics with more advanced inference, but I understand the pragmatic reasoning behind it. +1

[eddyb]

It's hard to produce disagnostics if you can't parse the source.
Also, typed holes are not a kludge, check out http://hazel.org.

[joshtriplett]

ping @cramertj @michaelwoerister @nikomatsakis

[FrankSD]

Anyone still working on this?

[varkor]

@estebank: you need to resolve your previous concern, for FCP to begin.

[estebank]

@rfcbot resolve unneeded

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[estebank]

I've been thinking about this and in the implementation we probably should support underscore with these suggestions anywhere we accept types, not just return type annotations, like function arguments and let bindings.

[vi]

Will it automatically recommend using impl Trait?

fn qqq() -> _ {
    |x:i32|{x+1}
}

Will it also work in generators / async fns?

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[eddyb]

@estebank For function arguments you'd need global inference to actually know the type, other than that, the only thing you could reasonably do today is turn the _ into a hole of some sort which doesn't unify with anything (but really, that's no better than writing () or !).

As for let bindings, those are always inside bodies, so _ just works (it means "infer this").

@vi Only if we special-case it for closures.

[varkor]

@eddyb: are you able to provide mentoring instructions for @FrankSD?

[eddyb]

I sadly don't have a lot of time to spend on this, but I can give some quick pointers here, and can answer questions on IRC/Discord later, if that helps.

The goal is to use something like this (which is the type -> impl Trait was inferred to be):

rust/src/librustc_typeck/collect.rs

Lines 1226 to 1235 in c3b8ab5

	// existential types desugared from impl Trait
	ItemKind::Existential(hir::ExistTy {
	impl_trait_fn: Some(owner),
	..
	}) => {
	tcx.typeck_tables_of(owner)
	.concrete_existential_types
	.get(&def_id)
	.map(|opaque| opaque.concrete_type)
	.unwrap_or_else(|| {

When computing a function signature:

rust/src/librustc_typeck/collect.rs

Lines 1657 to 1669 in c3b8ab5

	TraitItem(hir::TraitItem {
	node: TraitItemKind::Method(sig, _),
	..
	})
	| ImplItem(hir::ImplItem {
	node: ImplItemKind::Method(sig, _),
	..
	}) => AstConv::ty_of_fn(&icx, sig.header.unsafety, sig.header.abi, &sig.decl),
	Item(hir::Item {
	node: ItemKind::Fn(decl, header, _, _),
	..
	}) => AstConv::ty_of_fn(&icx, header.unsafety, header.abi, decl),

But only if the return type in the signature is hir::TyKind::Infer, and the function has a body (so not method declarations in traits without a default - or maybe not trait methods at all).

To avoid a cyclical dependency, this should also check for hir::TyKind::Infer return type, and use AstConv::ty_of_fn itself instead of calling tcx.fn_sig(def_id):

rust/src/librustc_typeck/check/mod.rs

Lines 835 to 836 in c3b8ab5

	let fcx = if let Some(decl) = fn_decl {
	let fn_sig = tcx.fn_sig(def_id);

As for where to get that inferred return type in type_of: you'll find it in the node_types map on TypeckTables, keyed by the return type (the hir::TyKind::Infer one).

[eddyb]

Oh and you'll have to emit an error at one of those points (I'm thinking fn_sig), with the inferred type, to present it to the user and at the same time guarantee compilation doesn't finish.
(For good measure, I'd also add a delay_span_bug to check/mod.rs)

[vi]

guarantee compilation doesn't finish

Maybe it would be nice to have some #![feature] flag to replace the error with a warning? It may be useful for prototyping, when the code is still in #![allow(unused)] era.

cargo fix should automatically type in the inferred type for me based on such warning.

[eddyb]

Downgrading this to a warning would require a RFC, AFAIK.
As for cargo fix, I would expect it to be able to fix errors, too.
(Although the compiler can't exactly give you a nice type to replace the _ with)