Skip to content

Introduce a T_err type for type errors #1871

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
catamorphism opened this issue Feb 21, 2012 · 7 comments
Closed

Introduce a T_err type for type errors #1871

catamorphism opened this issue Feb 21, 2012 · 7 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR)

Comments

@catamorphism
Copy link
Contributor

fn main() {
  let f = 42;

  let _g = if f < 5 {
      f.honk();
  }
  else {
    12
  };
}

If I compile this code, I get two error messages for (basically) the same span:

/Users/TimChevalier/silly.rs:5:6: 5:12 error: attempted access of field honk on type int, but no method implementation was found
/Users/TimChevalier/silly.rs:5       f.honk();
                                     ^~~~~~
/Users/TimChevalier/silly.rs:5:6: 5:14 error: mismatched types: expected function or native function but found ()
/Users/TimChevalier/silly.rs:5       f.honk();
                                     ^~~~~~~~

This kind of thing gets annoying fast. Would it be reasonable to only print an error message for the smallest sub-span when there are multiple error messages such that one span encloses the other? (In this case, the spans aren't exactly the same, but we should see the first error and realize "oh, we don't need to print out the second error, since its span is a superspan of the other")

@nikomatsakis
Copy link
Contributor

An alternative might be to try and avoid reporting derived errors. In this case, for example, the second error occurs because we assign the type of unit to undefined fields (I think that was my fault, but I'm not sure). It would be perhaps nicer to assign a special type (T_err or some such) indicating a compile-time error and then not report type errors that relate to T_err.

@catamorphism
Copy link
Contributor Author

That would also be totally plausible in this case! I think a similar situation might come up with user-generated errors and so the approach I suggested would be more general, but I can't think of an example right now.

@marijnh
Copy link
Contributor

marijnh commented Feb 21, 2012

Assigning ty_bot should actually also work -- that unifies with everything. (Though it'll probably add spurious unreachable statement warnings that have to somehow be suppressed.)

@marijnh
Copy link
Contributor

marijnh commented Feb 21, 2012

#1504 outlines another possible solution.

@catamorphism
Copy link
Contributor Author

Since no one has jumped on this, I'd like to fix it when I get a chance... but I don't know when that will be.

@ghost ghost assigned catamorphism Jul 29, 2012
catamorphism added a commit to catamorphism/rust that referenced this issue Nov 21, 2012
This allows more errors to be non-fatal, as per rust-lang#1871.

I only went through and started changing span_fatal to span_err in
check.rs. There are probably more errors that could be made
non-fatal.
@catamorphism
Copy link
Contributor Author

Done, pending review.

@nikomatsakis
Copy link
Contributor

Glad to see progress on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR)
Projects
None yet
Development

No branches or pull requests

3 participants