If actual declaration is broken (missing explicit `actual` keyword),
expect declaration still makes sense.
This way, we allow refactorings on broken code
^KT-65191 fixed
- The module structure for these tests was set up backwards: We should
keep the test module kind of the main module flexible (as it is
configured by test configurators), but keep the module kinds of the
binary libraries fixed.
^KT-65960
^KT-64994
- `LibraryBinary` should not contain any decompiled files, as we want
FIR symbols in tests to be provided from indexed stubs or class files,
but definitely not from decompiled PSI. This brings `LibraryBinary`
much closer to the behavior of binary libraries in the IDE.
- Some tests may still require access to a decompiled file, for example
when trying to test `getOrBuildFir` for some `KtElement` coming from a
library. This commit introduces `LibraryBinaryDecompiled`, which
does contain decompiled files.
- We don't really need `LibraryBinary` as a main test module kind
anymore, since tests generally want to access some main `KtFile`.
Hence, test configurators for `LibraryBinary` have been turned into
configurators for `LibraryBinaryDecompiled`.
- An alternative would be decompiling files on demand, but this is not
currently feasible because the Standalone API doesn't reconcile stubs
with decompiled PSI, like the IDE does automatically. (For the same
declaration, the stub and the PSI will have a different identity.) As
long as there is no support for this, we'll have to rely on a separate
test module kind.
^KT-65960
- `TestModule.explicitTestModuleKind` requires a directive to be present
to get the `TestModuleKind`. But we still want to find out the test
module kind for test modules without a directive. Hence, we have to
add this property to `KtTestModule` during its construction.
^KT-65960
When a symbol X from a binary library A uses another symbol Y from
another binary library B, `LLFirDependenciesSymbolProvider` cannot
resolve Y for X. This is because the existing
LLFirAbstractSessionFactory passes symbol providers for only builtin
libraries to `LLFirDependenciesSymbolProvider` even when the session has
dependencies. As a result, when `LLFirDependenciesSymbolProvider`
searches a symbol, it can find only symbols from the builtin libraries,
but it cannot find a symbol from libraries other than builtin libraries.
This happens only for the binary libraries.
^KT-65240 Fixed
This commit adds code to check whether a deserialized cone type is a
special function type kind or not when resolving the type of a lambda
expression (anonymous function). If it is a special function kind, it
sets the type of lambda based on the special function kind.
^KT-64994 Fixed
The test infrastructure for analysis supports binary module tests, but
the binary build does not use another binary module as a dependency when
it passes the class path. As a result, each binary module build does not
work when they have dependency on each other.
This commit fixes the issue by
1. Topological sort in the order of dependency graph for test modules.
2. Pass module paths as extra class paths when they have dependency on
each other.
^KT-64994
Allow multiple bases with default
implementations as long as there's a
non-abstract symbol from a class.
Our rules for Kotlin are stricter than
those in Java.
Check all members for `Visibility.Unknown`,
otherwise we miss them when they come
from supertypes. This is the reason why
the FP intellij build failed with a
cryptic stacktrace instead of a
human-readable diagnostic.
Also, do report the diagnostic at all
cases of `Visibilities.Unknown`. Turns
out, there are no "simple to reason
about" situations here :(
Also, an interesting detail:
`retrieveDirectOverriddenOf` returns an
empty list for intersection overrides.
But this doesn't seem to break anything...
Replacing `CANNOT_INFER_VISIBILITY`'s
type `KtDeclaration` with
`PsiNameIdentifierOwner` and the related
changes in `PositioningStrategies`
were needed to prevent an exception saying that
`PsiClassImpl` is not a subtype of
`KtDeclaration`.
All existing tests use custom test data for FIR because the diagnostic
text in FIR has to have a dot at the end. Also, the K2 checker doesn't
check usages in imports because there are no "import checkers" in K2
right now, this will need to be fixed later if necessary.
#KT-60797 Fixed
`testIntersectionOfPrimitiveBasedFunctions`
is fine, because we deprecate this
already in ^KT-63243.
`CANNOT_INFER_VISIBILITY` is
positioned as `DECLARATION_NAME`,
just in case we decide for
some reason that we do want to
report it along with
`MANY_*_NOT_IMPLEMENTED`. In that
case, we'd get a problem that
their bounds overlap, but not
completely contain one another.
^KT-63741 Fixed
^KT-59400 Fixed
The root cause of the exception is that we missed such an element, and
it led to unresolved declaration during iteration over file declarations
^KT-65562 Fixed
Suggest removing explicit type arguments when the upper bound is a
captured type since the only way to satisfy the upper bounds is
by letting the type variable be inferred to its bound.
#KT-65681 Fixed
The diagnostic target source element
type was changed to prevent crash due
to `checkPsiTypeConsistency()` in
`duplicateParameterNameSimplified.fir.kt`
^KT-65584
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
This only affects delegation operators as well as the for-loop-related
next and hasNext operators.
All the other operators worked correctly before.
In K2, the previously mentioned operator calls will be flagged with a
deprecation error and will become and error in 2.1.
#KT-59782 Fixed
Now we have only one FirDesignation instead of `FirDesignation`,
`FirDesignationWithFile` and `FirDesignationWithScript`
This allows us to unify situations with `FirFile` and `FirScript`
in the path and unbind from `FirRegularClass`.
This commit only refactors code, the semantic is still the same yet
^KT-65345
Before, auto-completion was based on on-air resolve, and
'FirTowerDataContext' was computed once, during creation of the
dependent analysis session (with using 'FirTowerDataContextCollector').
This allowed to return the context almost instantly, no matter how many
completion candidates there were.
Dangling file resolution doesn't use 'FirTowerDataContextCollector', as
now there is more precise 'ContextCollector'. However,
'ContextCollector' doesn't cache results by itself, and, if asked, it
will compute the same context over and over again. This exact happened
with extension applicability checker.
The optimized implementation maintains a checker object which caches the
computed context. The old end-point is left to give the IDE plugin time
to adapt to the change.
^KTIJ-28445
This diagnostic is reported on an explicitly-declared function which
overrides a regular Java function with the same signature as a hidden
one from the same scope.
#KT-64846 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
Marco Pennekamp