It would be great if we could to access file name,...
# language-proposals
m
It would be great if we could to access file name, line number and maybe column number and function signature in Kotlin source code. Like
#file
and
#line
in Swift /
__FILE__
and
__LINE__
in C languages (for the latter see: https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID390). Values should be resolved at compile-time, not at run-time like for exceptions. That would be great for improving diagnostic logging in Kotlin DSLs, so that the DSL user has a rough idea where an error that has been reported by the DSL library has originated from. Exceptions won’t help here since in many cases you cannot throw them at the moment that a function has been invoked. Validation may take place at the very end. Also, using stack traces to get that info adds a lot of overhead at runtime and isn’t available in multiplatform/common code.
3
i
r
If you are interested in getting this feature earlier... this could also be generated with a compiler plugin that generates source code constant values based of each element of the PSI tree before analysis resolves.
But definetly as proposed in the issue will be a better long term solution
m
That would require all library users to install the plugin, wouldn't it? 🤔
r
Yes, same as with serialization etc. They would need the plugin to pregenerate the values and terms they can refer as such as function names in the scope they are on.
But what you need to build this is a very stable part of the compiler because you can do this with PSI which is part of the IDEA open api for plugins and rarely change and in the future also FIR
m
Would still be nice if there is a default, so that library users don’t have to set up a compiler plugin for that 🤔 Could be a standard function in the lib with some intrinsic implementation which can be overriden by plugins.
r
Conceptually in meta when we have user macros, those expose the quote templates in the user code allowing libraries to access the AST previous to analysis so when we have macros this is also very easy to implement just with PSI
Agreed, this would be a good Lang feature compiler plugins aside
m
I have no idea what you mean re macros 😄 Have an example at hand?
You can transform any source tree in place or spit out sources like kapt does with a filter and transform function
The compiler analysis phase invokes that before resolution and type checking
If your expansion is valid Kotlin it will compile your expansion in the user sources
So implementing access to the file name, function name, source location etc. It's easy with metaprograming since you can generate those identifiers in all scopes statically as constants
And give users access to call them in their code at runtime
The macro expands them before compilation
m
Interesting 😮 So, this is for building compiler plugins with an API that is simpler than the yet-to-be-defined-one by the Kotlin team?
r
Yes
m
Or is it code that rewrites itself?
r
That is what meta does
Arrow Meta is a platform for building compiler plugins and access to the entire Kotlin compiler and ide with a high level api
Once Kotlin has a solid story or assimilates the concepts of meta we will get rid of it 😊
We need arrow meta for arrow to build union types, refined types, type classes and others
m
ok, I release a library that wants to do some codegen, the library user would add my library for runtime and Arrow Meta compiler plugin. My library’s runtime code (which I guess has some metadata for that?) would then apply code transformation when the project that uses the library compiles?
r
You build a plugin depending on meta and you release your plugin to a repository. The user adds your plugin to the list of Gradle plugins in their build. That's it
Meta takes on from there even installing the IDEA Plugin if you are doing something visual
m
ah okay
fancy 🙂
r
Hahah yeah, more hacky than magic but we are hoping for JB to realize that the IDEA experience for community plugins is far from desirable
Idea should auto recognize any plugin a project declared it depends on and autoinstall it
m
Plugins as in Gradle plugins, compiler plugins or IDE plugins?
r
Instead community plugins are hidden in a modal window that looks like a marketplace
All
m
I don’t even bother starting going down that rabbit hole at the moment. I made one feature for the IDE which I’ve PR’d and that was enough insight for a start 😄
r
I feel there is unnecessary gatekeeping around community plugins in general creating a lot of friction for library authors and users worldwide
m
Wel, there’s room for improvement everywhere 🙂 Not sure what their priorities are.
r
You have to search for stuff to setup your project when your project already outlines what it depends on. It's like it's still 1996 in plugin land.
I have offered myself and others to fix this at the root if anyone is interested in letting us from JB or of IDEA
m
Kotlin is also in a unique position that almost everyone uses the same IDE (for now). That wasn’t the case for any other language support by IDEA in the past.
“in 47”?
r
47 Degrees, the company where I work sponsors Arrow and Meta and we have an interest in community plugins to be more accessible than they are now. I manage that team and I can provide help to fix this issues if JB or the IDEA devs are currently busy with other priorities which we totally understand.
m
Interesting. Thanks for all that info 🙂
👍 1