New conformance tag '# E[tag!]' to require at least one success - #2354
New conformance tag '# E[tag!]' to require at least one success#2354srittau wants to merge 8 commits into
Conversation
|
I don't mind this, but just so you know: I generally just tried to work around this by not using int in these scenarios and using str literals instead, which don't have the promotion issues. In your specific case I might have used: I don't think that the promotion details matter for readers of the spec. |
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
This seems fine to me as a tool to have, though like @davidhalter I suspect that there is a better way to address the motivating case (we should always avoid using float as part of conformance suite examples, unless those examples are explicitly about the int/float special case) -- and if that leaves us with no use case for this, then it probably doesn't make sense to add it now.
| * `# E[tag]`, where `tag` is an arbitrary string: must appear multiple times in a file with the same tag. | ||
| Exactly one line with this tag must raise an error. | ||
| * `# E[tag+]`: like `# E[tag]`, but errors may be raised on multiple lines. | ||
| * `# E[tag!]`: like `# E[tag]`, but at least one line must not raise an error. |
There was a problem hiding this comment.
We should say explicitly here that zero errors also pass.
| ]: | ||
| """Return the line numbers where type checkers are expected to produce an error. | ||
|
|
||
| The return value is a tuple of two dictionaries: |
There was a problem hiding this comment.
I'm also thinking about replacing the second tuple item with either a string literal or an enum "single", "multiple", "require-success". This would make a cleaner API and make it more obvious that these three options are basically mutually exclusive. What do you think?
There was a problem hiding this comment.
Oh sorry I accidentally made a separate comment instead of replying here. If there are really just three supported/useful options, then I think an enum would be better than two booleans. (Better than using strings, too.)
There was a problem hiding this comment.
I've introduced the enum, extracted the logic that makes a decision based on this enum, and simplified the logic so that it should be obvious what's going on. The output doesn't change, indicating that the logic is (still) correct.
- Introduce an `ErrorMultiplicity` enum and return it from `get_expected_errors()`. - Extract `determine_group_error()` from `diff_expected_errors()` and simplify logic. - Rerun black on `main.py`.
3 participants
Extracted from #2353.
Necessary for pyrefly, which accepts both
assert_type(X, float)andassert_type(X, float | int), which other type checkers only accept either.Not super happy with the syntax, any other suggestions welcome.