Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Jeffset
Copy link
Contributor

@Jeffset Jeffset commented Apr 18, 2024

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.

Resolves #1232

Changes for the clients

  • if isError is true for a type, then the toString() for the type 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.

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.
Copy link

google-cla bot commented Apr 18, 2024

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.

@Jeffset Jeffset marked this pull request as ready for review April 18, 2024 18:22
@@ -1257,16 +1258,18 @@ class ResolverImpl(
argument.projectionKind != org.jetbrains.kotlin.types.Variance.INVARIANT
) {
// conflicting variances
// TODO: error message
return null
throw IllegalArgumentException(
Copy link
Contributor Author

@Jeffset Jeffset Apr 18, 2024

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()
Copy link
Contributor Author

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.

@Jeffset
Copy link
Contributor Author

Jeffset commented May 2, 2024

@neetopia @ting-yuan I wonder if we are ready to discuss the solution, if not, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose simple names on a missing types's synthetic declaration
1 participant