https://kotlinlang.org logo
Join Slack
Powered by
I'm trying to track down a problem with the kotlin...
# build-tools
c
I'm trying to track down a problem with the kotlin bazel rules, which seems to occur when you switch from pulling in kotlinc 1.3.40+. The compiler seems to have no problems if it's <= 1.3.31, but anything past 1.3.40+, with no infrastructure/rules changes, results in failure to see internal types and methods. Repeat, it's precisely the same rule infrastructure, so it builds 
-Xfriend-paths
and does all of that. The only variable is swapping in a later kotlinc. I can't find anything in the change-logs to indicate a change in internal/module enforcement in that timeline. Anyone know of changes that might affect internal enforcement and the behavior of 
-Xfriend-paths
?
s
The difference between the versions that caused me a problem was with a plugin that builds module-info.java of all sorts of things and it baulked over kotlin.native.concurrent because "native" is a java reserved word, that said, I don't know what bazel is or what "-Xfriendpaths" are. But you did mention modules!
c
Yeah - this is a different thing entirely. No kotlin native stuff involved here.
s
Ok, it was worth a try, there was no kotlin native stuff in mine either, the older kotlin stdlib doesn't contain kotlin.native and the newer ones do, I don't know why exactly, but the result is, doing moduley things just on the JVM can (or could, it's fixed now - for the jlink plugin) run into this.
a
@christiangruber likely due to this commit 
Check friend jars paths for exact match
https://github.com/JetBrains/kotlin/commit/db6a7779b841995a68a7dff25bf382acbd7ef2fb First public release with it is exactly 
v1.3.40
, 
1.3.31
didn’t have it
c
@artem_zin - Aha! Thank you. That looks about right. That should help me work this out.
a
👍 pls post an update here with your findings, I’m just curious but also we’ll hit it too one way or another 😄
c
Oh for sure. I'll actually update my rules fork with whatever I figure out.
👍 1
Still haven't gotten to this, but it's starting to get higher priority. Also, (side note) I'll be upstreaming my kotlin rules fork to the main bazel project, at their request, so I'll probably try to finish that before I tackle this. But we do need 1.3.50+ so I will get to this in the next couple of weeks, or early Q4 if I can't.
So... found it.
If you have one -Xfriends-path entry, it works fine. If you have two it doesn't. Why you might ask? Well, I asked myself that question. By the time I was done answering it, I was step-through debugging individual calls to kotlinc.
So it turns out with more than one entry in -Xfriends-path, the values in the path weren't being split. So the whole string was being passed in, not the individual path entries.
Why is THAT you may ask? Well... I also asked this.
First, I got fooled because I went hunting for the splitting code, and found. 
ArraysKt.filterNot(arguments.getFriendModules().split(File.pathSeparator), String::isEmpty)
That looks right, I thought to myself. So what's wrong?
That actually fooled me for about four hours of banging my head on my keyboard.
Until I realized that was in the K2JSCompiler class, not the java compiler.
It never occurred to me that they would treat this differently... and they do.
In the java it's: 
environment.configuration.getList(JVMConfigurationKeys.FRIEND_PATHS)
- a whole different infrastructure.
So, a getList() on a property-like construct often has a comma-separated default, so I thought "fuck it, why not". Sure enough. When I separated with a comma, not a semicolon (or platform path separator), it worked.
I need to file a bug. You have to use two different separators for the two backends. Not even sure what the native one would do.
Ima have to file a bug.
a
dang, thanks for this investigation 👍
c
All fixed in the latest bazel rules release
37 Views
Open in Slack
PreviousNext
Powered by