Existing code for receiver generation accidentally worked in most cases
for object members imported by name. However, it generated strange
bytecode (such as
GETFIELD AnObject.INSTANCE
GETFIELD AnObject.INSTANCE
POP
), and worked incorrectly for augmented assignments.
#KT-21343 Fixed Target versions 1.2.20
#KT-21009 fixed
Cache version could be changed only when compiler is changed.
@InputFiles on `AbstractKotlinCompileTool#computedCompilerClasspath`
ensures that non incremental build is performed when compiler is changed.
Modifying language/api version should cause non-incremental build.
Implicit change (e.g. when versions are not specified, but the compiler
is updated 1.1->1.2) is handled by `AbstractKotlinCompileTool#computedCompilerClasspath`.
Explicit change is handled by `AbstractKotlinCompile#serializedCompilerArguments`.
This test introduces very special (for current implementation) case,
when we have smartcast indirectly, via some reified type parameter.
It covers recursive call inSmartCastManager.checkAndRecordPossibleCast(),
which wasn't previously covered by any test in testbase.
This is more correct because it'll allow the incremental package
fragment to be deserialized with the same analysis flags as the changed
sources. Currently it doesn't seem possible to add a reasonable test for
this fix because there are no flags relevant for JS except for
skipMetadataVersionCheck, which is experimental and thus doesn't require
a test
Original issue here - structure of VfsEvents,
when directory gets deleted, we receive only VFileDeleteEvent
for directory, but not it's content, so we should invalidate
all modules in which sources this directory located, and all
modules that located in such directory
Second problem - When VirtualFile was deleted it is impossible to
get ModuleInfo for it using getModuleInfoByVirtualFile
Third problem - stale references in cache, due cycle dependency
#KT-20987 Fixed
Currently there are two major phases in NI that report diagnostics: resolution parts and completion. They connected in method `KotlinCallCompleter.runCompletion` and previously diagnostics were collected in several places, from resolution atoms, partly from constraint system and partly from `CallResolutionResult`, some of them were lost.
To mitigate this problem, now diagnostics are not bind to the intermediate candidate, only to the result resolution candidate (overloaded or usual one). And all diagnostics are now collected in method `runCompletion`
Dmitry Petrov