`stickyPostconditions` are such conditions that are checked
every time after applying when a new lowering finishes its execution.
Right now we are using them only in JVM, and this is a blocker
for adopting Native approach for lowering execution.
In Native we are using
`SimpleNamedCompilerPhase<in Context : LoggingContext, Input, Output>`
as the common super type for all lowerings. Here we have `Input` and
`Output` that can potentially be different and `stickyPostconditions`
don't have much sense in that case.
`resolveDependencies` showed up as a hotspot when profiling due to `canonicalPath` doing a lot of file system calls.
`fileKey` is more efficient and should guarantee uniqueness (`canonicalPath` may fail in the case of hardlinks).
The new code is 3x faster in our use case.
This class should contain 'global' settings for reference shortening;
ATM it only contains the `removeThis` flag
In the future this setting might be merged together with
`ShortenStrategy` to be computed on per-element basis
- Since this documentation was written, the usages of contextual modules
have expanded beyond outsider files, for example to support `KtModule`
disambiguation for library elements. Hence, it was necessary to update
the documentation accordingly.
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
This commit handles situations when some annotation in deserialized code
has an empty array literal argument [] or even non-empty [something].
Before this commit, we tried to guess a type of this array by "resolving"
the relevant annotation class and looking into the corresponding
parameter. Sometimes it can work, but also it can provoke recursive
resolve e.g. when the annotation class is a nested class in the same scope.
In this commit we changed the behavior in the following way:
- first, for non-empty array literals in deserialized code we just
take the array type from the corresponding array literal element
- second, for empty array literals we no more try to "guess" anything.
Instead we approximate array type as Array<Any>, and later at FIR2IR
stage we use the corresponding parameter type instead. At FIR2IR stage,
everything is already resolved and problems with recursions are no more
possible.
#KT-62598 Fixed
Before this commit, we first tried to guess a type of array literal
in deserialized annotation (it's a strange heuristics which can
lead to SOE and maybe not needed at all, see KT-62598, KT-62929),
and then, if unsuccessful, took the type from the first literal element,
if any. Since the second heuristic is much more clear, safe, and
understandable, in this commit they were swapped.
This commit does not fix KT-62598 in general case,
but decreases a set of cases when it can occur to
empty array literals only.
See the commented line at the end of the added test.
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62957 fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
Since they are not `FirSmartCastExpression`s,
they are treated as proper original types,
thus leading to reporting errors instead of
warnings.
^KT-60095 Fixed
Also, remove setting the value of allowUnstableDependencies to true if
K2 is used because we want K2 to report errors (as K1 does) on
unstable-ABI dependencies.
#KT-61598 Fixed
Currently, PROPERTY_WITH_NO_TYPE_NO_INITIALIZER is reported for local
variables, but not reported for member or top-level properties. Add a
check to the common `checkPropertyInitializer` for when a property
type cannot be determined from the getter.
This also corrects a K1 versus K2 inconsistency, where K2 would allow
blocks from getters to determine property type instead of only allowing
expression bodies.
^KT-59935 Fixed
^KT-60117 Fixed
^KT-60123 Fixed
Even when createDefaultMultiplatformPublications=false and maven-publish
is applied it is required to create all publication-specific entities
such as tasks, configurations, components etc. In order to let users
to compose publications on their own.
^KT-62877 Verification Pending
Previously it was attached to RootSoftwareComponent which has
heavy initialization work, for instance it creates new configurations
upon creation. The `publicationDelegate` is used in
`idOfRootModule` and should not trigger RootSoftwareComponent
initialization. After the change `idOfRootModule` became cross-project
safe. I.e. Project `foo` can call `idOfRootModule` on project `bar`.
^KT-62877 Verification Pending
^KTIJ-27374 Verification Pending
Mutating projects data, particularly, adding new items to its
collections such as tasks, configurations and components is a potential
risk to lose these data during the import to IDE.
^KT-62877 In Progress
It's confusing + it's not really
correct. It checks properties of
LUB types rather than the original
ones, but if we want to replicate
K1, we should check the originals.
Ivan Kylchik