Note that the quick fix to implement header class works incorrectly when
that class has nested classes at the moment; this should be fixed
separately
#KT-15494 Fixed
#KT-18573 Fixed
Also support a quick fix to add 'impl' modifier (KT-18454), although it
doesn't work yet on classes because there's no error on them in the IDE
#KT-18087 Fixed
#KT-18452 Fixed
#KT-18454
Try to report most of the errors on the actual members of the impl
class. In many cases, there's a 1:1 mapping of header to impl class
members, so the error "some members are not implemented" on the class
declaration itself is redundant. Exceptions include functions/properties
from supertypes (there may be no other place to report a signature
mismatch error in this case), functions/properties not marked with
'impl' (the checker is only run for declarations explicitly marked with
'impl') and default constructors (the checker is not run for them)
#KT-18447 Fixed
Try to report most mismatch errors on the 'impl' declaration. Only
report a mismatch error on the 'header' declaration if no error would be
otherwise reported on any 'impl' declaration in the compilation unit.
Also render declaration kind in the message
#KT-18447 In Progress
We set it to 1 now, because otherwise there is examples where
incorporation work too long. We will fix such cases in the future,
but seems like 1 is also good depth delta for incorporation
When there is multiline polyadic expression with some operators
J2K should keep surrounding parentheses, otherwise
operators will be dangling due resolved to prefix variant
#KT-17379 fixed
The problem in KT-19833 is caused by the fact that the application
environment instance is shared between consecutive runs of the compiler
in one Make action (KotlinCoreEnvironment.ourApplicationEnvironment).
If the JDK 8 module is compiled first, the created application
environment has no JRT file system, and once the JDK 9 module is
compiled later, that environment is not recreated and thus classes from
JDK 9 are unresolved.
To mitigate this, split the CoreJrtFileSystem implementation into the
file system itself which is global per application, and CoreJrtHandler
which is bound to a particular JDK home location. CoreJrtVirtualFile
paths now consist of the path to the JDK home, the "!/" separator, and
the path to the file itself, e.g.
"/usr/lib/jvm/java9!/modules/java.base/java/lang/Object.class". The
implementation is inspired by CoreJarFileSystem & CoreJarHandler.
No tests added because the application environment is _not_ shared in
tests. Also, a JDK 9 module is going to be added to the Kotlin project
soon, and that will serve as a test
#KT-19833 Fixed
Introduced new model for resolution result: tree of ResolvedAtoms.
Moved all postprocessing for arguments to front-end module.
Do not create freshDescriptor -- use freshTypeSubstitutor directly.
Removed Candidates for variables+invoke.
Add lazy way for argument analysis -- do not analyze all arguments
if we have subtyping error in first argument, but if we want report
all errors, then all arguments checks will be performed.
Future improvements:
- optimize constraint system usage inside ResolutionCandidate
- improve constraint system API
- improve diagnostic handlers
In front-end we have other ConstraintSystemCompleter and because of this
in dist we have ambiguity(because there all src folders compiles inside
same module.
Alexander Udalov