Stabilize termination_trait, split out termination_trait_test

[tmandry]

For #48453.

First time contribution, so I'd really appreciate any feedback on how this PR can be better.

Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[tmandry]

cc @nikomatsakis

[nikomatsakis]

r? @nikomatsakis

[nikomatsakis]

@tmandry

First time contribution, so I'd really appreciate any feedback on how this PR can be better.

Woohoo, welcome! <3

[nikomatsakis]

This looks great! My one concern is whether we can improve that error message in the case of a bad return type for main. I fear it is going to be confuse people as is.

[nikomatsakis]

Hmm, this is not your fault, but this error message seems less clear than before.

@estebank -- can we improve this readily enough with a #[rustc_on_unimplemented] annotation perhaps?

[estebank]

Yes, you could annotate std::process::Termination using #[rustc_on_unimplemented] to replace the error message to something appropriate. The only limitation is not knowing wether the requirement came from a return type or anywhere else, so the message will have to be more generic than it is now.

[tmandry]

It looks like there is already a #[rustc_on_unimplemented] annotation, but it is not used in the error message for some reason.

[tmandry]

Nevermind, once I cleaned my rustc build the note showed up. But since it's a label, not the primary error message, I had to use the error-message: directive to match against it.

[estebank]

For what it's worth, you have further control on the rustc_on_unimplemented output by being able to set a separate message and label, as well as customize either one for specific types.

That way, after including Niko's span change you could have the following output:

error[E0277]: `main` can only return types that implement `std::process::Termination`, not `i32`
  --> src/bin/termination-trait-main-i32.rs:11:18
   |
11 | fn main() -> i32 {
   |              ^^^ can only return types that implement `std::process::Termination`
   |
   = help: the trait `std::process::Termination` is not implemented for `i32`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.

[estebank]

since it's a label, not the primary error message, I had to use the error-message: directive to match against it.

You didn't need to use error-message, you could use

//~^ NOTE `main` can only return types that implement std::process::Termination, not `i32`

instead for labels.

[tmandry]

I updated the tests to reflect the error label that's already there from rustc_on_unimplemented. Here's what the full output looks like:

error[E0277]: the trait bound `i32: std::process::Termination` is not satisfied
  --> src/bin/termination-trait-main-i32.rs:11:18
   |
11 |   fn main() -> i32 {
   |  __________________^
12 | | //~^ ERROR the trait bound `i32: std::process::Termination` is not satisfied [E0277]
13 | |     0
14 | | }
   | |_^ `main` can only return types that implement std::process::Termination, not `i32`
   |
   = help: the trait `std::process::Termination` is not implemented for `i32`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.

[nikomatsakis]

@tmandry ok, so, that is looking better! the main problem is that the span we are giving for the error (i.e., the region in the source code that we highlight) is the function body, which makes it cross multiple lines and makes my eyes glaze over (I imagine others have the same reaction). Let me see if I can give any tips about how to get a better span.

[nikomatsakis]

the span is specified here; if you look up to line 1028 you can see it comes from the body:

rust/src/librustc_typeck/check/mod.rs

Line 1028 in 5ccf3ff

let span = body.value.span;

In general, to get a good span, you want to look to the HIR, which corresponds pretty closely to the input program. In this case, we want to look at the argument decl:

rust/src/librustc_typeck/check/mod.rs

Line 1001 in 5ccf3ff

decl: &'gcx hir::FnDecl,

The FnDecl struct is declared here:

rust/src/librustc/hir/mod.rs

Lines 1718 to 1727 in 5ccf3ff

	/// Represents the header (not the body) of a function declaration
	#[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug)]
	pub struct FnDecl {
	pub inputs: HirVec<P<Ty>>,
	pub output: FunctionRetTy,
	pub variadic: bool,
	/// True if this function has an `self`, `&self` or `&mut self` receiver
	/// (but not a `self: Xxx` one).
	pub has_implicit_self: bool,
	}

We want to get the span from the return type, for which there is a convenient method:

rust/src/librustc/hir/mod.rs

Lines 1815 to 1820 in 5ccf3ff

	pub fn span(&self) -> Span {
	match *self {
	DefaultReturn(span) => span,
	Return(ref ty) => ty.span,
	}
	}

So basically the span should be something like:

let return_ty_span = decl.output.span();

and use that instead of span.

[tmandry]

Thanks for your help! I agree, the error message is much better this way. Updated and converted one of the tests to a UI test.

[nikomatsakis]

@tmandry 🏂

[nikomatsakis]

cc @rust-lang/docs -- I want to r+ this PR! It stabilizes fn main() -> T { } where T: Termination (though not the termination trait itself). What kind of documentation is needed and where?

[nikomatsakis]

According to @aturon, for edition-related docs we're going to handle them out of band. Therefore, I'm allowed to r+.

@bors r+

[bors]

📌 Commit 72334fe has been approved by nikomatsakis

[nikomatsakis]

@tmandry nice work

[nikomatsakis]

@bors r-

[nikomatsakis]

So, it does look great, but I did just want to make two comments:

It does seem like it'd be marginally better to use the E0580 code, so that we can have a --explain output that is tailored to this case. I can help @tmandry with the answer to this question:

since I'm not sure how to go from here to librustc::infer::error_reporting where E0580 is used (or vice versa)

in one second.

Regarding what @scottmcm wrote:

One thought: is there a canonical "I don't really care I just want to use ?" Result type we could point people to?

Interesting point. I don't think though that there is :( -- I wish that Result<_, Box<Error>> would work but for Reasons I don't think it will really will, and I don't think that Box<dyn Debug> would work because there needed Into clauses don't exist.

[nikomatsakis]

@bors r+

Ugh. OK, digging into the code I see what @tmandry was tempted to leave it the way they did. =) It's a bit annoying to use E0580. I'm sort of inclined to land this now, and leave that for possible follow-up. So r+ again.

One interesting thing is that E0580 is also issued for things unrelated to the return type -- e.g., supplying arguments, or making main unsafe or the wrong ABI. So in a sense maybe using E0580 isn't the best option. If we did want to do it, we would create a refactored helper function somewhere that both the error-reporting modules can call into. But this code is in dire need of some refactoring.

Anyway, thanks @tmandry for all the effort you've put into this.

[bors]

📌 Commit 2b13d95 has been approved by nikomatsakis

[estebank]

@nikomatsakis I just realized that it could make sense to allow rustc_on_unimplemented to set an error code but I'd be worried about over/mis-use...

[scottmcm]

Filed rust-lang/rfcs#2367 to track coming up with a good return type to suggest.