4 Commits

Author SHA1 Message Date
Evgeniy.Zhelenskiy 7eab4b672d [K1, K2, CLI] Mark whole position range of compiler diagnostics in CLI
#KT-64989
2024-02-08 12:59:31 +00:00
Kirill Rakhman 5b9c35de2e [Tests] Update test data with error suppression warnings
#KT-61129 Fixed
2023-08-18 13:29:20 +00:00
Alexander Udalov b10cc6657e Fix loading of builtins resources in kotlin-reflect in Java modular mode
The main change here is that when kotlin-reflect is being run under Java
9+, we use another implementation of BuiltInsResourceLoader (see
libraries/reflect/api/src/java9) which loads .kotlin_builtins files from
the java.lang.Module instance of kotlin-stdlib, instead of the class
loader of kotlin-reflect, which may not have access to those resources.

If the application is being run in the old (classpath) mode, that Module
represents the unnamed module, which contains everything on the
classpath, and everything works as before. But if it's being run in the
modular mode, that Module instance is an encapsulated module for
kotlin-stdlib classes and resources, exactly where .kotlin_builtins
files are located.

This fixes a regression in 1.4.0. Prior to 1.4, kotlin-reflect and
kotlin-stdlib were not named modules (see KT-21266) and were loaded as
_automatic_ modules even if the application was run in the modular mode.
Apparently, they shared the same class loader in that case and looking
up .kotlin_builtins resources worked.

This change was supposed to go alongside
828cc6dbf3, but was overlooked because
adding module-info to standard libraries was postponed at that point.

Also slightly refactor Java9ModulesIntegrationTest to simplify running
compiled code, and add a smoke test on using kotlin-reflect in modular
mode.

 #KT-40842 Fixed
2020-08-24 13:30:00 +02:00
Ilmir Usmanov 1336e8f3e3 Take java 9 modules into account in coroutines debug metadata
reading
 #KT-28237
2018-12-06 16:59:15 +03:00