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
#1232: Include type hint into KSErrorType. #1848
base: main
Are you sure you want to change the base?
Conversation
This CL makes `KSErrorType` a class with a string "hint", that by convention should be a "simpleName" of an unresolved type. `KSErrorTypeClassDeclaration` is also no longer a singleton and references a corresponding `KSErrorType`. The implementation consists of extracting the available info on the unresolved type on the best effort basis.
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
@@ -1257,16 +1258,18 @@ class ResolverImpl( | |||
argument.projectionKind != org.jetbrains.kotlin.types.Variance.INVARIANT | |||
) { | |||
// conflicting variances | |||
// TODO: error message | |||
return null | |||
throw IllegalArgumentException( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took liberty in making this an exception. My argument is that returning an error type in a situation seemingly close to an internal error is a bit weird, maybe it's better to crash. If we are not ready to make such decision here, please tell me, and I'll revert to returning null
and later on an error type.
@@ -125,7 +125,7 @@ class KSClassDeclarationImpl private constructor(internal val ktClassOrObjectSym | |||
|
|||
override fun asType(typeArguments: List<KSTypeArgument>): KSType { | |||
if (typeArguments.isNotEmpty() && typeArguments.size != asStarProjectedType().arguments.size) { | |||
return KSErrorType | |||
return KSErrorType() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this (and similar) cases, where an error type is used to signal the incorrect API usage rather than to represent a truly missing/unresolved type, I've decided to not provide any additional hints. If that's not okay or if I've misinterpreted something, let's discuss the matter.
@neetopia @ting-yuan I wonder if we are ready to discuss the solution, if not, please let me know. |
This CL makes
KSErrorType
a class with a string"hint", that by convention should be a "simpleName" of an unresolved type.
KSErrorTypeClassDeclaration
is also no longer a singleton and references a correspondingKSErrorType
.The implementation consists of extracting the available info on the unresolved type on the best effort basis.
Resolves #1232
Changes for the clients
isError
is true for atype
, then thetoString()
for thetype
will "likely" return a meaningful value in a format of"<ERROR TYPE: SomeSimpleName>"
, of<ERROR TYPE>
(as before) if no info was available.KSErrorType
and their synthetic declarations will now be separate instances.This is the first iteration; if API changes are needed and/or other issues are uncovered, I'm ready to work on them. If my approach to solving the original issue is presumed to be OK, I may write more tests for error types in addition to the existing ones.