Treat number literal that represents minimum integer as integer node in
JS AST.
Treat +<number_literal> JS AST as unary node (+) containing single
number literal
There are cases when it's impossible to distinguish which JS node
owns location denoted by source map. Consider example:
a + b
Both root JsBinaryNode and its arg1 point to the same start location.
Out translator provides full information, though parser can't
produce the same AST. The second AST will miss some of the locations
available on the first one. This processor gets AST node produced
by translator and removes locations from there so that both ASTs
become equal.
JS source map remapper takes parsed source maps
together with JS AST with correct JS positioning information
and converts the latter into Kotlin positioning information
If the compiler is invoked through JPS, an instance of
XmlMessageRenderer is used and the output should be a valid XML.
Previously, we reported the argument parse error (and the note to try
"-help") before calling messageRenderer.renderPreamble, which resulted
in invalid XML. The same was happening for the usage printed on "-help".
Both of these problems are fixed
#KT-14848 Fixed
Invalid compiler arguments should lead to a compilation error, not
internal error. This has been fixed by splitting the
"parseArguments(...)" call (which does parsing + validation) in
CompileServiceImpl into two calls of parseCommandLineArguments +
validateArguments, and returning with a compilation error if the latter
did not succeed
#KT-16057 Fixed
#KT-14848 In Progress
Add a test for applying kotlin-android plugin with com.android.feature
Add a test for Databinding (not passing yet with 3.0.0+, until
3.0.0-alpha4 is released, which contains the fix from the Android side).
Add missing test project android-databinding.
Refactor and improve the tests
* Remove redundant files from test project 'android-databinding'
* Refactoring and minor improvements in the tests
- 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'
Alexey Andreev