function lifetime elision changed in 1.64

[QuineDot]

I tried this code:

fn foo<'a>(_: &'a str, _: &'a str) -> &str { "" }

I expected to see this happen:

error[E0106]: missing lifetime specifier
 --> <source>:1:39
  |
1 | fn foo<'a>(_: &'a str, _: &'a str) -> &str { "" }
  |               -------     -------     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
help: consider using the `'a` lifetime
  |
1 | fn foo<'a>(_: &'a str, _: &'a str) -> &'a str { "" }
  |                                       ~~~

error: aborting due to previous error

Instead, this happened: Successful compilation

Meta

Tested on the playground, all versions and editions.

• Stable channel: 1.64.0
• Beta channel: 1.65.0-beta.3 (2022-10-10 da7ffa2)
• Nightly channel: 1.66.0-nightly (2022-10-19 4b8f431)

Notes

I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet.

@rustbot label +T-compiler +A-lifetimes +regression-from-stable-to-stable

[Noratrieb]

searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01
regressed nightly: nightly-2022-07-26
searched commit range: 7fe022f...6dbae3a
regressed commit: 6dbae3a

bisected with cargo-bisect-rustc v0.6.4

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --access github --timeout 30 --start 2022-01-01 --end 2022-10-01 --regress success 

@cjgillot

[Noratrieb]

@rustbot claim

[Noratrieb]

Actually, this behavior is correct as documented by the reference:

If there is exactly one lifetime used in the parameters (elided or not), that lifetime is assigned to all elided output lifetimes.

There is exactly one lifetime used in the parameters ('a), so assigning it to the output lifetime is as expected.
@rustbot release-assignment

[QuineDot]

That verbiage has existed since 2017 but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) The nomicon mirrors the RFC in specifying input positions, not counts.

Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional.

@rustbot label +T-lang

[apiraino]

Ok, so we will consider this for now a P-critical regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

[cjgillot]

Filed #103450

[jackh726]

Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

[Mark-Simulacrum]

Discussed in lang, dropping nomination.

Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window).
Considering whether we want to make the behavior change can happen in a follow-up proposal.