Skip to content

dropck: track order of destruction for r-value temporaries #22323

Closed

Description

@pnkfelix

Spawned off of #21022, #21972; see also #21657.

Tracking order of destruction for r-value temporaries would (probably) allow us to resume writing code like this from RFC 769:

for line in old_io::stdin().lock().lines() {
    ...
}

which is currently disallowed because the region inference system does not know that the temporary yielded by stdin() will outlive the temporary from stdin().lock().

(But note that it might also have fallout, potentially worse than that of #21657)

Activity

  1. pnkfelix commented on Feb 14, 2015

    @pnkfelix
    ContributorAuthor
  2. steveklabnik commented on May 24, 2016

    @steveklabnik
    Contributor

    Triage: not aware of any changes here, but it's also not an area I'm super familiar with.

  3. pnkfelix commented on May 25, 2016

    @pnkfelix
    ContributorAuthor

    I assume MIR and non lexical lifetimes will likely resolve this directly

  4. added
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    and removed on Jul 22, 2017
  5. pnkfelix commented on Jul 30, 2018

    @pnkfelix
    ContributorAuthor

    According to

    error[E0597]: `y` does not live long enough
    this does not appear to be fixed by NLL.

    Update (circa September 2018): Oh, that test is an instance of #46413, not this.

  6. pnkfelix commented on Jul 30, 2018

    @pnkfelix
    ContributorAuthor

    (which is ... okay, but a little surprising, and perhaps worth investigation after we've taken care of the other bigger problems in NLL.)

  7. pnkfelix commented on Jul 30, 2018

    @pnkfelix
    ContributorAuthor

    I'm just going to throw in a reference to the NLL tracking issue #43234 in the hopes that we remember to look at this again later.

  8. self-assigned this
    on Jul 31, 2018
  9. 4 remaining items

  10. pnkfelix commented on Sep 19, 2018

    @pnkfelix
    ContributorAuthor

    I investigated. NLL does fix the problem described in this issue.

    My earlier comments regarding cases that don't work are instances of misclassification on my part; they should have been associated with #46413 and perhaps #21114

  11. added
    E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.
    fixed-by-NLLBugs fixed, but only when NLL is enabled.
    and removed on Sep 19, 2018
  12. added a commit that references this issue on Sep 27, 2018
  13. removed
    E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.
    on Sep 27, 2018
  14. pnkfelix commented on Nov 8, 2018

    @pnkfelix
    ContributorAuthor

    Visited for T-compiler triage. Removing NLL-fixed-by-NLL issues from the Release milestone, but continue to leave them open as issues themselves.

  15. removed this from the Rust 2018 Release milestone on Nov 8, 2018
  16. removed their assignment
    on Nov 9, 2018
  17. added a commit that references this issue on Mar 11, 2019
    65cb35a
  18. added 3 commits that reference this issue on Apr 22, 2019
    bf0ea60
    c21fbfe
  19. added a commit that references this issue on May 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-NLLArea: Non-lexical lifetimes (NLL)A-lifetimesArea: Lifetimes / regionsC-feature-requestCategory: A feature request, i.e: not implemented / a PR.fixed-by-NLLBugs fixed, but only when NLL is enabled.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions