Skip to content

Elaborate interface signature errors#5777

Merged
sandersn merged 8 commits into
masterfrom
elaborate-interface-signature-errors
Dec 2, 2015
Merged

Elaborate interface signature errors#5777
sandersn merged 8 commits into
masterfrom
elaborate-interface-signature-errors

Conversation

@sandersn
Copy link
Copy Markdown
Member

Thanks @RyanCavanaugh for this -- it just needed one small change to pass kind into the error reporting.

Can you take a look at the new-and-improved signature errors? The change adds a line to many errors, which is more correct but also more verbose.

Signature errors were not reported before.
Comment thread src/compiler/checker.ts Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs to be if (localErrors) {...} because you only want to report this error if you haven't reported other errors already. If you look at the changes in all of the tests you'll see what I mean. There are a bunch of "Signature has no corresponding..." errors that are out of place because there actually was a corresponding signature for which you've reported the reason that it wasn't compatible.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example here. You've already reported why the signatures aren't compatible, so it doesn't make sense to say there isn't a corresponding signature.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Thanks, I thought it was over-reporting.

Accept the new baselines based on this change. Gets rid of a lot of
redundant errors.
And accept baselines
@ahejlsberg
Copy link
Copy Markdown
Member

Error baselines look much better now. 👍

Comment thread src/compiler/checker.ts Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add documentation to localErrors where it's defined? Also, give it a better name because I don't think it accurately reflects the functionality.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, good point. I changed the name to reportMoreErrors.

Change `localErrors` to `reportMoreErrors` to more accurately reflect what
the variable does.
Comment thread src/compiler/checker.ts Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just call it shouldElaborateError.

@sandersn
Copy link
Copy Markdown
Member Author

@DanielRosenwasser should I go ahead and merge now? I don't really want to add a way to distinguish global.*Type. :)

sandersn added a commit that referenced this pull request Dec 2, 2015
…-errors

Elaborate interface signature errors
@sandersn sandersn merged commit a4770af into master Dec 2, 2015
@sandersn sandersn deleted the elaborate-interface-signature-errors branch December 2, 2015 23:54
@sandersn
Copy link
Copy Markdown
Member Author

sandersn commented Dec 4, 2015

Fixes #5751.

@ahejlsberg
Copy link
Copy Markdown
Member

I'm not sold on this special casing of the apparent types of the primitives. I thought you had (correctly) concluded it wasn't worth the effort.

@sandersn
Copy link
Copy Markdown
Member Author

sandersn commented Dec 4, 2015

My objections are

  1. It's ugly.
    1. Checking the apparent type is redundant -- it's kind of the right thing at the wrong time.
    2. Checking for equality to a list of things encodes the knowledge in the wrong place -- the function isPrimitiveApparentType rather than the types themselves (apparent or otherwise).
  2. It's slow.

On the other hand, the error messages do get less noisy.

When I discussed it with @DanielRosenwasser in person, he pointed out that we are already in an error case, so (2) doesn't matter. And I decided that the small number of primitives (three) was not likely to change much, so it was worth it to get the shorter error messages.

If that analysis of the tradeoff isn't satisfying, I could change it back.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants