- The semantics of a non-static declared member scope should be as
follows: For a variable `c: C` of class type `C`, the declared member
scope should contain all members `x` accessible as `c.x` (visibility
notwithstanding) which are *also* explicitly declared in `C`.
- Classifiers are not accessible as properties of a variable `c`, only
as static members of the class `C` itself, so non-static declared
member scopes should not contain any classifiers.
^KT-61800
- `JavaClassDeclaredMembersEnhancementScope` actually had nothing to do
with Java enhancement, so it is easily replaceable with a more general
`FirDeclaredMembersOnlyScope`.
^KT-61800
- The function is mostly for convenience, but scope providers will be
able to optimize this scope if needed (similar to how combined
declared member scopes are already optimized).
- `getCombinedMemberScope` will be used by `KDocReferenceResolver`.
^KT-61900
- Now that combined declared member scopes for Java classes contain
static callables, we don't need to search symbols in the static member
scope. (Note that the static member scope is too broad for this use
case, as it contains symbols from superclasses, but we only need to
look at declared members because the correct `containingClass` is
already chosen.)
^KT-61901
^KTIJ-25126
- Now that non-static declared member scopes don't contain static
callables anymore, we have to update some usages in the Analysis API.
- In symbol light classes, many usages of `getDeclaredMemberScope` can
be kept as-is because Kotlin classes/objects generally cannot declare
static callables (and we do not need to create symbol light classes
for Java classes). The only exception are enum classes, which
implicitly declare some static callables.
^KT-61800
- Member scopes already don't contain static callables, only their
static member scope counterparts. However, declared member scopes
contained both non-static and static callables, which was confusing to
users. See for example KT-61255.
- Now declared member scopes only contain non-static callables and
static declared member scopes only contain static callables.
- In `KtFirScopeProvider`, the new implementation is different for
Kotlin and Java classes, because the standard declared member scope
doesn't work for Java. Instead, we have to get the Java *enhancement*
scopes from `JavaScopeProvider`. Unfortunately, `JavaScopeProvider`
doesn't have a direct enhancement declared member scope. This results
in a somewhat complex scope structure with the declared members filter
scope around the use-site/static Java enhancement scope, but since the
declared members filtering scope properly reduces the set of callable
names and scopes in general are cached, this shouldn't be an issue.
- `getCombinedDeclaredMemberScope` is introduced as a separate public
function because for Kotlin scopes, we don't actually have to create a
combined scope, as the non-static and static scopes are just filters
around a combined declared member scope provided by the compiler. It's
also important to have a convenient function to get the combined
declared member scope, because some usages explicitly want access to
all declared members (such as symbol light classes).
- This commit also fixes KT-61901, because
`getFirJavaDeclaredMemberScope` now provides a proper static scope for
Java classes, which will be accessible via the combined declared
member scope as well.
^KT-61800 fixed
^KT-61901 fixed
^KT-61255 fixed
When the left-hand side of an equality comparison is known to be a
String, and the equality condition resolves to true, then the right-hand
side can be smart-cast to a String as well. This was working for String
expressions on the left-hand side but not for String constants.
^KT-57513 Fixed
Removing nullability directives from the methods of anonymous classes
affects some bytecode listing tests, but the changes will take effect
only after the advancing of the bootstrap compiler version.
See ^KT-62044
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
When type parameters size doesn't match, it's better to pass `null`
instead of a parentSubstitutor. Before this commit we were creating an
invalid substitutor. Who knows what can go wrong because of that further
along the execution
Related issue: KT-54827
Related test: compiler/testData/diagnostics/tests/multiplatform/kt54827.kt
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation for the commit: There is no user report or anything. It's not
known whether these invalid substitutors were causing problems. I just
noticed this problem while doing substitutor API refactoring (see the
next commit).
Note: `ExpectedActualResolver.matchActualCallableAgainstPotentialExpects`
has the same problem. But since it's K1 I won't touch it
Anonymous functions (lambdas) are not allowed as annotation arguments.
However, because it is still possible to parse code written this way, it
must be handled without exception. So ignore these expressions when
processing annotation arguments.
#KT-59565 Fixed
Building with macOS gave the linker warning
`ld: warning: ignoring duplicate libraries: '/Users/foo/.konan/dependencies/apple-llvm-20200714-macos-aarch64-1/lib/libclangEdit.a'`
Remove duplication from the build script to get rid of the warning.
Co-authored-by: Dave MacLachlan <dmaclach@gmail.com>
References inside LC apis are build over `ClsJavaCodeReferenceElement`,
which simplifies resolve by providing precalculated data.
When refactorings or quick fixes do on the fly resolve,
giving only text and LC context,
such precalculated data is not available and normal resolve starts.
In order for this resolve to work correctly,
LC should provide available declarations
Corresponding test in monorepo: `KotlinSymbolOnAirResolveTest`
^ KT-62440 fixed
Despite the FUS services are intended to be scoped to a build, the legacy compatibility service wasn't properly managed and that caused a significant memory leak together with changes in KT-59826.
#KT-62318 In Progress
When friendPaths change, internal symbols from other modules become hidden
or visible. This might change which functions are called, which types
are returned, etc. So we should recompile the affected classes.
Gradle doesn't allow Input policy on FileCollection properties, so we
introduce friendPathsSet. It allows us to keep the ABI of BaseKotlinCompile
unchanged, detect non-incremental configuration changes on Gradle side,
and use normal incremental compilation for everything else.
^KT-61918 Fixed
Merge-request: KT-MR-12372
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
Scopes may return private symbols from
supertypes, they should not clash with
symbols from the current class.
For example, see:
`FirLightTreeBlackBoxCodegenWithIrFakeOverrideGeneratorTestGenerated.FakeOverride#testPrivateFakeOverrides1`
Lombok shouldn't generate functions if the
user has defined explicit ones.
In K1 generated functions are not really
added to the declared members scope.
^KT-61243 Fixed
Metadata compilation with name "main" isn't used in Hierarchical
Multiplatform. It used to compile commonMain source set to legacy
metadata artifacts. With Hierarchical MPP common source sets start
to compile to klib metadata.
GranularMetadataTransformation.ProjectData is created for all projects
There was a chance when it is created too early before some projects
evaluation. And if that happened that these projects contained some
subplugins (for example KSP) that add more source sets. Then old
algorithm of collecting sourceSetsMetadataOutputs() would fail with
ConcurrentModificationException. For example in this scenario:
Lets assume we evaluate sourceSetsMetadataOutputs for project with
just one common source set: commonMain.
And therefore one metadata compilation whose default source set name is:
commonMain.
On top of that a subplugin applied to this project. This subplugin
creates additional source set for each metadata compilation.
Then with old algorithm following would happen:
* start iterating over sourceSets
* for `commonMain` source set await its Metadata Compilation
* * When Metadata Compilation gets configured at some point of time
it will reach KotlinCommonSourceSetProcessor.doTargetSpecificProcessing
method. Which will apply subplugins.
* * When subplugin is applied it adds a new Source Set to
the sourceSets collections: CME is occurred!
Adding a source set in subplugins should be regulated
either allow it and fix related side effects OR deprecate it.
The current fix doesn't solve all potential issues with adding new
source sets from subplugins. It primarily focused on CME occurrence
for the case above.
^KT-62299 Verification Pending
Marco Pennekamp