Skip to content

Conformance tests: Add mechanism to allow errors on one of multiple lines #1680

Closed

Description

@JelleZijlstra

Sometimes type checkers differ on the exact line where an error is reported, e.g. issues with decorated functions may be reported on either the decorator line or the def line. For the automated conformance checking that I just added in #1678, we need some way to annotate such expected errors.

For example, this incorrect code produces a mypy error on line 3 and a pyright error on line 4:

from typing import final

@final
def f():
    pass

My proposed syntax is to add "# E or +1", meaning that an error should be reported either on the comment line or the line after. We would write the test case like this:

from typing import final

@final  # E or +1: @final must be used on a method, not a global function
def f():
    pass

Or alternatively:

from typing import final

@final
def f():  # E or -1: @final must be used on a method, not a global function
    pass

This syntax isn't the greatest but I haven't thought of anything better; suggestions welcome.

Activity

  1. erictraut commented on Apr 5, 2024

    @erictraut
    Collaborator

    I don't think this will be sufficient. There are cases where errors can be separated by many lines. These are typically related to overloads, overrides, or redefinitions. We haven't hit many of these yet because these areas are still (mostly) unspecified or under-specified in the typing spec, but they're all areas that will need to be spec'ed eventually.

    To handle cases like this in an automated way, we'd probably need to be able to tag multiple error sites such that they can be associated with each other. For example, we could use a numeric tag — something like # E[4]. If this appears on two or more lines, it would mean "this error should be emitted on one of these lines". That would be more flexible than a +1 or -1 syntax.

  2. JelleZijlstra commented on Apr 5, 2024

    @JelleZijlstra
    MemberAuthor

    To be clear I was envisioning that any number would be accepted, e.g. E or +3, but your solution is probably better because it doesn't require counting lines and marks every error location explicitly. I would modify it to say that the tag can be any string that is unique within the file, e.g. E[final1].

  3. added a commit that references this issue on Apr 5, 2024
    054b627
  4. added a commit that references this issue on Apr 6, 2024
    1466b3b
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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions