This commit updates the test output for the updated NLL compare mode
that uses `-Z borrowck=migrate` rather than `-Z borrowck=mir`. The
previous commit changes `compiletest` and this commit only updates
`.nll.stderr` files.
[NLL] Returns are interesting for free regions
Based on #53088 - creating now to get feedback.
Closes#51175
* Make assigning to the return type interesting.
* Use "returning this value" instead of "return" in error messages.
* Prefer one of the explanations that we have a name for to a generic interesting cause in some cases.
* Treat causes that involve the destination of a call like assignments.
Extract impl_header_lifetime_elision out of in_band_lifetimes
This way we can experiment with `impl Debug for &MyType` separately from `impl Debug for &'a MyType`.
I can't say I know what the code in here is doing, so please let me know if there's a better way 🙂
I marked this as enabled in 2018 so that edition code continues to work without another flag.
Actual feature PR https://github.com/rust-lang/rust/pull/49251; Tracking Issue https://github.com/rust-lang/rust/issues/15872; In-band lifetimes tracking issue https://github.com/rust-lang/rust/issues/44524.
cc @aturon, per discussion on discord earlier
cc @cramertj & @nikomatsakis, who actually wrote these features
add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint
This adds structured suggestions to the elided-lifetimes-in-paths lint (introduced in Nov. 2017's #46254), prevents it from emitting a false-positive on anonymous (underscore) lifetimes (!), and adds it to the idioms-2018 group (#52041).
~~As an aside, "elided-lifetimes-in-paths" seems like an unfortunate name, because it's not clear exactly what "elided" means. The motivation for this lint (see original issue #45992, and [RFC 2115](e978a8d301/text/2115-argument-lifetimes.md (motivation))) seems to be specifically about not supplying angle-bracketed lifetime arguments to non-`&` types, but (1) the phrase "lifetime elision" has historically also referred to the ability to not supply a lifetime name to `&` references, and (2) an `is_elided` method in the HIR returns true for anoymous/underscore lifetimes, which is _not_ what we're trying to lint here. (That naming confusion is almost certainly what led to the false positive addressed here.) Given that the lint is relatively new and is allow-by-default, is it too late to rename it ... um, _again_ (#50879)?~~
~~This does _not_ address a couple of other false positives discovered in https://github.com/rust-lang/rust/issues/52041#issuecomment-402547901.~~
r? @nikomatsakis
cc @nrc @petrochenkov
The existing elided-lifetimes-in-paths lint (introduced in Nov. 2017's
accd997b5 / #46254) lacked stuctured suggestions and—much more
alarmingly—produced false positives on associated functions (like
`Ref::clone`) and on anonymous '_ lifetimes (!!—yes, the very
anonymous lifetimes that we meant to suggest "instead"). That this
went apparently unnoticed for so long maybe tells you something about
how many people actually bother to flip on allow-by-default lints.
After many hours of good old-fashioned American elbow grease—and a
little help from expert reviewers—it turns out that getting the right
answer is a lot easier if we fire the lint while lowering the Higher
Intermediate Representation.
The lint is promoted to the idioms-2018 group.
Also, in the matter of test filenames, "elided" only has one 'l' (see,
e.g., https://en.wiktionary.org/wiki/elide).
Resolves#52041.
- On mismatch between impl and trait method, point at the trait
signature.
- Point only at the method signature instead of the whole body on
trait/impl mismatch errors.
When refering to named lifetime conflict, point only at the method's
signature span instead of the entire method.
When the expected and found sup and sub traces are the same, avoid
redundant text.
