Don't drag function signatures along function item types.

[eddyb]

This PR separates the signature of a function from the "function item type" (TyFnDef), leaving only the DefId and parameter Substs, making them even more like (captureless) closure types.

The motivation for this change is reducing typesystem complexity, and its consequences:

• operating on the signature instead of just the parameters was less efficient
  • specifically, signatures can easily add several levels of depth on top of the parameter types
  • and the signatured were always substituted and normalized, so typically even more complex
• it was the only type that was both nominal (identity) and structural (signature)
  • harder to model in Chalk than either a purely nominal or structural type
  • subtyping worked on the signature but parameters were always invariant
  • call type-checking was transforming signatures but keeping the nominal half intact
  • the signature could therefore get out of sync during type inference in several ways

That last point comes with a [breaking-change], because functions with 'static in their return types will now not be as usable as if they were using lifetime parameters instead:

// Will cause lifetime mismatch in main after this PR.fnbar() -> &'staticstr{"bar"}// Will continue to work fine, as every use can choose its own lifetime.fnbar<'a>() -> &'astr{"bar"}fnmain(){let s = String::from("foo");Some(&s[..]).unwrap_or_else(bar);}

r? @nikomatsakis

[petrochenkov]

Is it okay that signatures are not folded anymore? (Is it possible to fold something kept in the tables at all?)
It would be really nice if they were at least still visited by default.

[eddyb]

The whole point (which I'll try to describe once I'm sure there's no fatal flaw with the approach) is to reduce the amount of work done for these types. Anything that relied on seeing the signature has to visit it manually. It's not a property of the type and it was never meant to be, it's just one way to use values of that type (i.e. calling them).

[Mark-Simulacrum]

@bors try

This will get us artifacts for cargobomb.

[bors]

⌛ Trying commit 198067e with merge c7ced21...

[bors]

💔 Test failed - status-travis

[Mark-Simulacrum]

Don't retry until the previous try finishes one way or another.

[Mark-Simulacrum]

@bors try

[bors]

⌛ Trying commit 87a65f2 with merge ebf4c15...

[Mark-Simulacrum]

Oh right

@bors retry

[bors]

⌛ Trying commit 87a65f2 with merge ab0e704...

[bors]

☔ The latest upstream changes (presumably #42362) made this pull request unmergeable. Please resolve the merge conflicts.

[eddyb]

Started crater run (fingers crossed it's fixed now).
EDIT: it's not.

[tomprince]

@bors try

[eddyb]

@bors try

[bors]

⌛ Trying commit 2a64a2d with merge aa4570a...

[tomprince]

I've started a cargobomb run of this.

[bors]

💥 Test timed out

[bors]

☔ The latest upstream changes (presumably #42504) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 69076f3 has been approved by nikomatsakis

[bors]

⌛ Testing commit 69076f3 with merge 4079e61...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 4079e61 to master...

[jethrogb]

This is stabilizing in 1.20 (Thursday). I realize this is probably a little late, but can we add a better error message when people encounter this breaking change? You now just get a generic borrow check error. Easy to test with the example from the first PR comment.

[eddyb]

@jethrogb Are you talking about the example itself or have you seen this in the wild in another form? And no, you can't detect this without reintroducing the complex representation removed here.

[jethrogb]

@eddyb I just came here from the draft release notes. I haven't actually encountered any broken code myself. I do think it's fairly common for people to write &'static str as a function return type, so I think this error is likely to come up during development. The error message doesn't imply "you can fix this with a reborrow" which will likely be the case.

I don't exactly understand how this change makes detecting this harder but maybe some kind of heuristic (instead of a guaranteed detection) is good enough. Alternatively, maybe we can make a documentation change somewhere.

[eddyb]

You only get an error if you pass such a function to another function that usually takes a closure.
Reborrows on immutable references don't usually do anything.

[jethrogb]

I meant this is a way to fix the code above:

Some(&s[..]).unwrap_or_else(||&*bar());

[eddyb]

Oh and the canonical fix is to make the 'static into a lifetime parameter.
In your snippet you can remove the reborrow. || bar() is the fix there, the reborrow is redundant.

[jethrogb]

Oh and the canonical fix is to make the 'static into a lifetime parameter.

Sure but the user doesn't always have a choice in that regard. Popular crates use &'static str in their return types:
https://docs.rs/toml/0.4/toml/value/enum.Value.html#method.type_str
http://docs.diesel.rs/diesel/query_source/trait.Column.html#tymethod.name
https://docs.rs/slog/2.0.9/slog/struct.Record.html#method.file

[eddyb]

Fair enough, the second best choice is introducing a closure (like you did, if you ignore the reborrow).