In both these situations, we have some.HashMap & java.util.HashMap
from explicit star importing scope, and kotlin.collections.HashMap
from implicit star importing scope after it.
K1 ignores both explicitly imported classifiers due to their ambiguity,
and then resolves to kotlin.collections.HashMap at the next level.
In contrast, K2 takes explicitly imported classifiers and
properly reports ambiguity.
In this test, both frontends resolve to fun Semaphore.
Both work this way because interface/class Semaphore classifiers are
clashed (ambiguity) and ignored.
K2 reports ambiguity for some similar cases,
but constructor resolve still ignores ambiguous classifiers when found.
(see FirScope.processConstructorsByName in ConstructorProcessing.kt)
In this test, K1 resolves to kotlin.collections.HashMap /* = java.util.HashMap */
K2 does the similar, but fun processConstructors from ConstructorProcessing.kt
makes a type alias substitution, so in fact constructor of expanded
java.util.HashMap is processed.
Pay attention that both frontends ignore some.HashMap and java.util.HashMap
due to ambiguous classifiers in explicit star importing scope.
See FirScope.processConstructorsByName in ConstructorProcessing.kt
Before, we were wrapping the original constraint position into
ConeBuilderInferenceSubstitutionConstraintPosition twice during the
constraint substitution in builder inference.
It was causing problems with diagnostic reporting.
Remove TODOs about diagnostic reporting from FirBuilderInferenceSession.
Propagation of errors from the common system is now implemented
Diagnostic reporting in updateCalls isn't needed, since we
report errors after the system completion unlike K1
Relates to KT-53749
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
This commit actually does two things:
- Adds Any scope to stub type
- Makes CheckDispatchReceiver treat stub types
as non-null for the unsafe call check to make such candidates viable
Related to KT-59369
In certain situations like constructor calls, it's possible
to have different WasExperimental/SinceKotlin pairs associated
with one use-site, e.g. a constructor call is associated both
with a constructor declaration and a class declaration.
However, looks like it make no sense to handle this situation
in FirSinceKotlinHelpers, because FirOptInUsageBaseChecker already
handles them.
#KT-59825 Fixed
When an inline lambda is invoked or passed to another inline function,
make sure non-local returns are allowed by all surrounding declarations.
Otherwise, NON_LOCAL_RETURN_NOT_ALLOWED must be reported.
^KT-59884 Fixed
^KT-55319 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
ARGUMENTS_OF_ANNOTATIONS will be dropped, so this check should be moved
This commit also drops class annotations resolution from implicit type
phase and provides the correct scope during argument mapping phase.
This code was effectively unreachable before
^KT-62679
K1 reports `ARGUMENT_TYPE_MISMATCH`
and `TOO_MANY_ARGUMENTS` together, and
one way to do it in K2 is to say that
their kinds of inapplicability difference
is not relevant to the user.
Note that K1 doesn't do such filtering,
so this change "makes K2 closer to K1",
but still different.
^KT-62541 Fixed
fixup! [FIR] Show ARGUMENTS_MAPPING_ERROR diagnostics along with INAPPLICABLE
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
This commit handles subtle situation when K1 represents flexible type
arguments as just T..T?, but K2 does it as T&Any..T?.
This can provoke a type like Captured(*)&Any..Captured(*)?,
and before this commit we couldn't find recursion inside Captured(*)&Any.
This could lead to explosions inside type system and inference errors
#KT-60581 Fixed
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
Mikhail Glukhikh