https://kotlinlang.org logo
Join Slack
Powered by
would it be feasible to write a compiler plugin th...
# compiler
a
would it be feasible to write a compiler plugin that asserts every non-annotated thing is NonNull, but interprets 
Optional<T>
as 
T?
?
r
You can provide your own type checker implementation or Ir phase and insert in the Ir phase the implicit conversions from and to Optional <-> ?
You can then intercept in IR and insert the casts where needed. This could potentially be generalized as a plugin for implicit conversions between typed values.
The remaining piece you’ll need is synthetic descriptors for IDEA so it does not red line it as a type error
we still haven’t figured out that part in Arrow meta
a
what's ir phase?
d
(backend) IR is a tree-like intermediate representation of code used in compiler backend to generating bytecode/js/bitcode IR Phase is thing that can transform IR you can take a look to related code in 
compiler/ir
modules in 
kotlin
project
You can provide your own type checker implementation
Note that this way is not a part of public compiler API, so it may be dangerous
All public extension points are listed in 
idea/resources/META-INF/extensions/compiler.xml
r
yes, replacing the typechecker is dangerous. In our case we just make the kinds and their concrete type be considered subtypes of each other which is a safe implicit conversion. Here is how we replace it. Ideally the Kotlin type checker is also part of an extension point in future compiler plugins since type checking expressions is such a big part of metaprogramming. https://github.com/47deg/arrow-meta-prototype/blob/master/compiler-plugin/src/main/kotlin/arrow/meta/extensions/MetaComponentRegistrar.kt#L368-L370
As you can see we create a composable function 
registerKindAwareTypeChecker(): ExtensionPhase.StorageComponentContainer
that can be mixed in in any plugin that needs the kind aware type checker. An example of Arrow-meta creating a high level feature from a small set of interceptions. These blocks are not constrained to a single phase like in this case, you can return multiple interceptions from code parsing all the way down to resolution, codegen, etc.
@Adam Spofford Feel free to rip off any code you need from the prototype for your project, this will all eventually come out as ASL2 and with credits and attributions to the Kotlin compiler and all other libs it depends on.
d
yes, replacing the typechecker is dangerous
it's dangerous because of that API can be changed in any release
r
Agreed, but since there is no official support for compiler plugins that is also true for all other apis including public ones. Our only hope is that since other companies like google are writing plugins something will be done about it at some point before everyone depends on the full blown compiler API
a
@dmitriy.novozhilov if that is a bad way to do this, what is a good way?
note that I'd much rather not have the use of Optional even visible, and am looking for more of a way to change how Kotlin sees Java code.
like how kotlin.String despite actually being java.lang.String still has a bunch of methods that the latter doesn't
d
unfortunately there is no good way, because we have no extension points in compiler frontend that can modify resolve
a
nuts
r
Resolution can also so be contributed without extension points. https://github.com/47deg/arrow-meta-prototype/issues/10
Many of the resolution services are singleton and would need to be replaced like in the type checker example but some other services related to resolution like the BodyResolver can be just contributed to the container with useImpl
3 Views
Open in Slack
PreviousNext
Powered by