Skip to content

Implement fail as a macro/library function #2232

Closed

Description

@brson

It will not be difficult to eliminate fail from the language, but there are some considerations: a) it has to work with or without an argument (we could just have two); b) in the future it will probably need to accept any sendable type argument, not just a string; c) it has to report the correct location of the error.

Activity

  1. nikomatsakis commented on Apr 17, 2012

    @nikomatsakis
    Contributor

    (c) seems to argue for a macro. The macro could also address (a) without requiring two distinct forms. (b) seems easy enough to solve using generic types.

  2. catamorphism commented on Apr 19, 2012

    @catamorphism
    Contributor

    I opened an issue - #2245 - for the #file and #line macros that we need for this.

  3. kud1ing commented on May 24, 2012

    @kud1ing

    #2245 is implemented now

  4. eholk commented on May 25, 2012

    @eholk
    Contributor

    I thought another key feature of fail was that typestate knew it never returned and could stop checking after branches that fail. Can we do that with a macro?

  5. brson commented on May 26, 2012

    @brson
    ContributorAuthor

    eholk: we also have the '!' return type that gives us the same information, so we can presumably declare in intrinsic that returns !

  6. eholk commented on May 26, 2012

    @eholk
    Contributor

    Oh right, I forgot about that.

  7. ghost assigned on Jul 6, 2012
  8. bblum commented on Jul 18, 2012

    @bblum
    Contributor

    With this issue, do we intend to tear out the unwinding bits in the runtime, too? Or just have it call into task::fail which calls rustrt::rust_task_fail?

  9. elliottslaughter commented on Jul 23, 2012

    @elliottslaughter
    Contributor

    This has been (partially) implemented in de82a9b, although the current version is a very thin wrapper around the C runtime.

    Eventually (i.e. when I finish GC), the GC will handle running any destructors on the stack, making unwinding unnecessary. I've got a partial patch at https://github.com/elliottslaughter/rust/commits/unique-ptrs, but it doesn't yet know about non-pointer resources on the stack.

  10. elliottslaughter commented on Jul 23, 2012

    @elliottslaughter
    Contributor

    This issue seems like a subset of #2861, yes?

    Edit: No, actually. This involves language changes, whereas #2861 is only concerned with the runtime implementation.

  11. z0w0 commented on Feb 16, 2013

    @z0w0
    Contributor

    I think this is done now.

  12. catamorphism commented on Feb 16, 2013

    @catamorphism
    Contributor

    Done as of 172c29f

  13. added a commit that references this issue on Sep 22, 2022
  14. added a commit that references this issue on Jan 29, 2025
  15. added a commit that references this issue on Aug 21, 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-codegenArea: Code generationA-grammarArea: The grammar of RustA-type-systemArea: Type systemE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions