Android Gradle Plugin 3.0 and 3.1 use aapt that does not handle
long paths on Windows. This commit uses shorter paths for the project
working directory on Windows.
Test: running integration tests on Windows
The phase determines which transformers were already applied to declaration.
The transformer controls current resolve phase in phasedFir and
performs additional resolve if necessary.
That component is responsible to run all resolution stages on candidate
and calculating resulting applicability.
This is needed for completion of `when` and `try` as function calls
There was a problem when we get type from type projection even if
it is a star projection what is meaningless. Now we try to fold argument
only if it's not a star projection
Otherwise StackOverflowError or recursion-detection in LockBasedStorageManager
may happen
It's fine to have non-refined type there because it only can affect
content of containing type member scope that should be refined after
being requested
Previously, type for "c.a"-receiver in "c.a.platformFun()"
has not been refined because typechecking of "c.a" doesn't go
through common facade org.jetbrains.kotlin.types.expressions.ExpressionTypingServices#getTypeInfo
where the most of expressions are expected to be type checked.
(see org.jetbrains.kotlin.resolve.calls.CallExpressionResolver#getUnsafeSelectorTypeInfo)
Note that Native built-ins are not resolved correctly in this module
(CPointed and similar). This is not a bug, but rather a technical
limitation of the current testing infrastructure: we can't depend on
kotlin-native stdlib in "big-Kotlin" repo, and native stdlib is used as
the only one source of Native built-ins.
Under COMPOSITE mode we don't have a globally known way to create
built-ins, instead, we have to create them on per-module basis.
So, in this commit we:
1. Use builtInsProvider: (ModuleInfo) -> KotlinBuiltIns instead of
precomputed builtIns instance, in order to be able to calculate
builtIns on per-module basis
2. Introduce new entity, called BuiltInsCache, which, roughly
speaking, is a map of form ModuleInfo -> KotlinBuiltIns, to prevent
creation of multiple builtInsInstances
NB. Actually, it's of form BuiltInsCacheKey -> KotlinBuiltIns, because
we shouldn't create new builtIns for each module. Also, currently,
each platform has its own BuiltInsCacheKey implementation, because
parameters by which built-ins are created, are a bit different across
different platforms. Ideally, we should eliminate those differences
and they use one concrete implementation as a key.
Under COMPOSITE resolution mode (see ResolutionModeComponent) we have
no fixed and globally known SDK, instead, for each module we have to
find SDK it it's transitive dependencies.
Currently, this is necessary in order to create proper JvmBuiltIns,
which need dependency on SDK to be present in immediate dependencies.
Previously, each ProjectResolutionFacade was tied to the respective
platform, so there were no point in collection moduleInfos for all
possible platforms.
For composite resolution mode, we have to get all modules no matter
what their platform is (because all modules will be analyzed in one
facade), so this commit adds such an ability.
Alexey Tsvetkov