Before refinement, order of accessing compiler's entities (supertypes,
descriptors, memberscopes) was always the following:
sources -> libraries -> SDK (built-ins)
With refinement, it is sometimes possible to inverse this order, e.g.
access sources after libraries or SDK. This mainly happens in the following
scenario:
- we reference some library/SDK class, but do not acquire source-lock
This might seem a bit weird, but actually it is quite easy to achieve
as soon as we understand that analysis sources doesn't necessarily
acquires respective lock, only forcing lazy computations does so.
E.g., we can just traverse PSI tree and meet some refernce to "Any?" -
this doesn't involves acquiring source-lock
- we start resolving it, which usually involves acquiring library/SDK-lock
(e.g., in order to get it supertypes or memberScope)
- because we reference it from the source-module, we may like to refine
it, in which case we will have to acquire source-lock on refinement
cache
Obviously, that may lead to deadlocks, so, in this commit we disable
creating granular locks when we work with refinement.
Note that if refinement is disabled (which is the case for all non-MPP
projects), we still create separate locks.
This commit introduces the ability to register a PlatformExtensionClashResolver
in a container. Each PlatformExtensionClashResolver has a corresponding
PlatformSpecificExtensions.
If, during container composition, several instances of
PlatformSpecificExtensions were registred, instead of throwing
InvalidCardinalityException, corresponding PlatformExtensionClashResolver
will be asked to resolve clash.
This allows to make injection more composable and less coupled across
different contributors of service, providing a basis for such motivating
cases as composing containers with both JS and JVM services (for analysis
of multiplatform modules).
Previously, that would be impossible:
a) JS would inject default instances for some services which would clash
with non-default JVM services (like SyntheticScopes)
b) Also, there are a very few services for which *both* platforms provide
non-default implementations, so they should be merged manually on
case-by-case basis (e.g., IdentifierChecker)
The idea is to try to resolve the dependency without considering default
instances first.
This makes containers more composable, e.g., it is now possible to put
several containers together as long as all except one provide default
implemenetation for some particular service (non-default implementation
will be automatically chosen, and all defaults will be discarded).
Set LATEST_STABLE language version and current version of stdlib to 1.3, set IS_PRE_RELEASE
Remove "EXPERIMENTAL" from 1.3 version description in tests and gradle options
We're suspecting that the culprit of such errors is race condition on
'supertypes' in AbstractTypeConstructor, when it is created using
'LockBasedStorageManager.NO_LOCKS'
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Affected cases:
- return type for suspend lambda
- aliased type in type alias declaration
- using type alias instead of aliased type in declarations
#KT-23345 Fixed
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
Nikolay Krasko