report error for unsolved type variables in function calls#1749
report error for unsolved type variables in function calls#1749KotlinIsland wants to merge 1 commit into
Conversation
6ff7dcd to
c5fcd37
Compare
This comment has been minimized.
This comment has been minimized.
868276b to
09ecbcc
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
the example from that issue still doesn't report an error:
a = []There was a problem hiding this comment.
the error message is pretty confusing in this case:
Type variable "T" has no solution; consider providing it explicitly
maybe for list/set/dict/etc. literals it should give an example of how to fix it, eg:
Type variable "T" has no solution; consider providing it explicitly (eg.
list[int]())
maybe that can be a diagnostic addendum
There was a problem hiding this comment.
I don't think I like suggesting
a = list[int]()
when
a: list[int] = []
would have better performance.
09ecbcc to
e6e8b07
Compare
This comment has been minimized.
This comment has been minimized.
|
@DetachHead ci failed for some flake i think, wanna review? |
|
that can happen if you push the same commit multiple times, it tries to publish a canary version that already exists |
e6e8b07 to
2d8d629
Compare
This comment has been minimized.
This comment has been minimized.
2d8d629 to
441dfac
Compare
There was a problem hiding this comment.
i think the primer has raised some false positives, or at least scenarios that need investigating
This comment was marked as duplicate.
This comment was marked as duplicate.
| } | ||
| }, | ||
| { | ||
| "code": "reportUnsolvedTypeVar", |
There was a problem hiding this comment.
I'm not sure I like this name.
"Solving" a type variable is a perspective of the type-checker implementer, that the type-checker user shouldn't need to think about.
The user doesn't need to think about "solving" things, or "solutions".
This kind of seems like something for the family of reportUnknown... rules.
reportUnknownTypeVar?
There was a problem hiding this comment.
while the term is possibly confusing since type checkers seem to have different words for it (pyright uses the word "specialize" but idk if that term is unique to pyright), i don't consider the actual resolving of a type var to be an implementation detail. the user should be able to clearly tell when using a function or class with a generic whether that generic was able to be inferred or not, regardless of what word is used to describe that process.
i agree reportUnknownTypeVar sounds like a better name, and is more consistent with other similar rules
resolves: report an error when a type variable cannot be resolved #1499
depends on: remove unused generic from
argparse._ActionsContainer.add_argumentpython/typeshed#15585