- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
... and use it as prefix to FQN in inline functions. This allows
to properly inline function declared in module A to module B,
when this function calls another function in module C.
See KT-18201
When a Kotlin identifiers contains non-ES5 chars, JS BE
either reports error (for published declarations) or mangles name
(for non-published ones). The old approach relied on wrong
assuption that Java identifier = ES identifier.
However, that's not true. This commit introduces functions that
check identifiers according to ES5.1 spec rather than
using Character.isIdentifierStart[Part]
See KT-17476
Friend modules should be provided using the -Xfriend-modules flag
in the same format as -libraries. No manual configuration required for
JPS, Gradle and Maven plugins.
Friend modules could be switched off using the -Xfriend-modules-disabled
flag. Doing that will
* prevent internal declarations from being exported,
* values provided by -Xfriend-modules ignored,
* raise a compilation error on attemps to use internal declarations from other modules
Fixes #KT-15135 and #KT-16568.
Local declarations obtain names prefixed with outer function's name.
Only simple name (i.e. without mangling) of outer function used
in this case. This raises a problem in case of inline functions
with object literals. Currently, they are not copied, but exported
from module. Consider two inline functions foo with different
signatures, both declare object literals. In this case both literals
are exported as foo$f, so only one will be accessible from outside.
The <Type>Array.iterator used to lack next<Type>() method (KT-16626).
The -Xtypedarray compiler key enables translation of primitive arrays
to TypedArrays, and primitive array`is`-checks (KT-15358, KT-14007,
KT-14614, KT-16056).
Allow the compiler to read such libraries without any errors, at the
risk of crashing with an exception.
Also fix a minor bug in the diagnostic message in LibrarySourcesConfig
and in the corresponding test in KotlinJpsBuildTest
Inject LanguageVersionSettings instead; all information relevant to the
analysis should be now passed via an instance of LanguageVersionSettings
(which should be renamed to a more general name in the future).
This is partially a revert of d499998 and related commits
This makes it possible to drop CompilerConfiguration from
CallCheckerContext, which in turn helps to avoid passing the entire
CompilerConfiguration instance through front-end
Previously ReflectionTypes.find returned an error class in case a class
is not found in the module dependencies. The problem with this approach
is that each call site should call ErrorUtils.isError on the result and
report an error if needed, in order to stop this type from reaching the
codegen, which can't handle error types.
Now we create a MockClassDescriptor instance instead. It's not an error
class, so it'll be handled correctly in the codegen. Also its scope is
empty and errors are reported on any non-trivial usage (see
MissingDependencyClassChecker), so this approach is not worse than error
classes
#KT-16484 Fixed
LanguageVersionSettings can be read from the configuration. Also, the
configuration may be used for other stuff, not related to language version
settings, soon
Mikhail Glukhikh