Skip to content

Replace fail invocations with ice_condition.raise in rustc #1928

Closed

Description

@brson

We should see if conditions can suit our purposes; we may not be able to get rid of every fail! invocation that rustc can reach, but it would not hurt to try.


Original title: Replace fail with session.bug in rustc

When possible rustc should be using session.bug or session.span_bug instead of fail because that prints out proper error messages.

Activity

  1. brson commented on Mar 5, 2012

    @brson
    ContributorAuthor

    Or, if it's a real error condition of course it should use fatal or error

  2. marijnh commented on Mar 6, 2012

    @marijnh
    Contributor

    I really think we should wire things up in a way that allows us to print out the error message from normal failure. Passing sessions to things that otherwise don't take sessions, just to be able to call session.bug, doesn't sound attractive. Not to mention that we're also calling library routines that can fail.

  3. brson commented on Mar 6, 2012

    @brson
    ContributorAuthor

    I'm inclined to agree. We need failure and logging to be more powerful.

  4. catamorphism commented on Mar 8, 2012

    @catamorphism
    Contributor

    Is it reasonable to consider this bug "postponed until error/logging infrastructure improves"?

  5. ghost assigned on Mar 8, 2012
  6. pnkfelix commented on Apr 23, 2013

    @pnkfelix
    Contributor
    1. The documentation in the comment above "pub fn monitor" in rustc.rc was quite helpful for me to get my head around our current setup.
    2. brson says we can probably close this, as "its probably not worth the effort to expunge all calls to fail! at this point"; however, marijnh's comment makes me pause before closing. Perhaps this represents some sort of weakness, if there really is not a way to make at least a best-effort attempt to extract the string passed to fail! (if any) from the parent task of the failing subtask...
  7. graydon commented on Apr 24, 2013

    @graydon
    Contributor

    This is an ideal candidate for conditions.

  8. added a commit that references this issue on May 6, 2013
  9. pnkfelix commented on May 6, 2013

    @pnkfelix
    Contributor

    I've got a sketch started over here: https://github.com/pnkfelix/rust/commits/issue1928-add-ice-condition

    (Most of the redundancies that I identified while doing it come from known problems in our macro and condition system.)

  10. pnkfelix commented on Jun 3, 2013

    @pnkfelix
    Contributor

    Note that some issues with conditions may need to be resolved first; e.g. #5446.

  11. thestinger commented on Aug 5, 2013

    @thestinger
    Contributor

    This is still an open issue.

  12. catamorphism commented on Oct 24, 2013

    @catamorphism
    Contributor

    Low, not 1.0. (Can be closed if we remove conditions.)

  13. alexcrichton commented on Mar 6, 2014

    @alexcrichton
    Member

    Conditions have been removed.

  14. added a commit that references this issue on Jun 4, 2024
  15. added 2 commits that reference this issue on Nov 2, 2025
  16. added 2 commits that reference this issue on Nov 30, 2025
  17. added 2 commits that reference 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

    C-cleanupCategory: PRs that clean code up or issues documenting cleanup.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.P-lowLow priority

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions