https://kotlinlang.org logo
Join Slack
Powered by
stupid question, given a KtParameter, how I could ...
# arrow-meta
t
stupid question, given a KtParameter, how I could check if the type is nullable or not, i only see, 
isMutable
i
When it comes to types the Descriptor API’s may help you. you can derive an Descriptor with methods like 
resolveDescriptorIfAny
or something like that.
if you paste in the code. I can help you.
a
@Imran/Malic, I think he's referencing the PsiElement system!
i
what system are you referring to? - I am confused by your naming.
a
He's working with the quote and template system and looking directly at 
KtProperty
in the Kotlin compiler
r
@thanerian you can try and see if this works
Copy code
fun KtParameter.isNullable(): Boolean =
  typeReference?.typeElement is KtNullableType
☝🏽 2
🙏 1
i
@amanda.hinchman-dominguez that doesnt limit him to get more information, about the node he is inspecting.
r
there isn’t much notion of nullability in psi until you get to descriptors. You can also always call 
.text
and parse out if it comes down to the worst case
👆 1
➕ 1
a
@Imran/Malic ^ what Raul said hahaha
You can also read what I put in the main chat to get more context about what we're doing
i
I think your missing that for many KtElements your able to access the underlying low level api’s. The PsiElement API’s are designed to contain less information, so that computations in tree traversals are kept small. Compared doing the same with AST-nodes or Descriptors, which is not performant at all. That’s why the Kotlin Plugin utilises those API’s to keep performance lean and dont blow up computations if not everything from an AST node or Descriptor is used. Generally, it looks a bit like this: PsiElement < Descriptor < AST Needless to say, not for every KtElement there is an Descriptor, but then you can use the AST APi’s directly, which may look like this:
Copy code
val astNodeForFunction: (KtNamedFunction) -> ASTNode = { f: KtNamedFunction -> f.node }
Once 
Fir
is done it will replace the Descriptor API’s, for better performance - among other things. Ref: https://kotlinlang.slack.com/archives/C7L3JB43G/p1575900125139300?thread_ts=1575895820.138400&amp;cid=C7L3JB43G
a
For this feature, we need the AST elements directly.
Descriptors actually depend on ASTs
As for FIR, FIR depends on Descriptors which depends on AST
i
😉 Everything in all 3 models is based on AST
a
Arrow-meta is meant to access all extension phases for the Kotlin compiler
right
So, we need this feature haha
d
As for FIR, FIR depends on Descriptors which depends on AST
@amanda.hinchman-dominguez 1. There won't be any descriptors in FIR at all 2. By AST you mean PSI?
☝🏽 1
a
@dmitriy.novozhilov you access AST through the PSI. @Imran/Malic brought in FIR when it's actually not relevant to this conversation at all
r
FIR is relevant in the sense that in the future quotes may also support FIR as output and meta will provide the same DSL as it provides for backend IR for it.
6 Views
Open in Slack
PreviousNext
Powered by