lambdaParameterForBareTypeEarlyFixationAffectsBehavior.kt
should show in the future commits how early variable fixation
necessary for bare type information might affect inference results
^KT-64840 Related
This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
Previously, it was failing at line
(resolvedReceiver?.toReference(session) as? FirNamedReferenceWithCandidate)?.candidate?.updateSourcesOfReceivers()
But this line was mostly incorrect because in case of `a.b()` call,
which is resolved to `a.b.invoke()`, `resolvedReceiver` is pointing to
`a` instead of obviously expected `a.b`.
The fix with using `candidate.callInfo.explicitReceiver` doesn't help
either because the candidate of that receiver is always completed at
that stage (so no Candidate there).
The only case when the candidate was still there is PCLA because
in that case we explicitly don't fully complete even receiver
expressions.
(see docs/fir/pcla.md)
The idea of the fix is moving the call of `updateSourcesOfReceivers`
for invoke property receiver to the place just before the candidate
is being converted to the resolved reference
(i.e., the candidate is being lost)
^KT-66148 Fixed
There's an implicit contract in PCLA that the statement-level call
should be postponed iff it has something to be postponed inside.
And that contract didn't work well for string interpolation containing
some postponed calls.
Thus, we haven't run a completion results writing for them properly,
thus leaving type parameters (K from synthetic call) for expression
types instead of an inferred substituted type.
In this commit, the contract was reversed to explicitly enumerate
the cases when it's safe to resolve the candidate outside PCLA session.
See the comments at `mightBeAnalyzedAndCompletedIndependently`.
^KT-65341 Fixed
- For synthetic calls
- For delegated constructor calls
Also, I checked that for each toResolvedReference() (beside annotations)
that converts candidate to the resolved reference,
we run `runPCLARelatedTasksForCandidate()` in the same context.
^KT-65103 Fixed
It's been used only for regular function call nodes resolution,
so I made it more explicit.
The main idea behind this change is ResolutionMode hierarchy
simplification and the kind of statement
that "AugmentedAssignmentCallOption" is only relevant to calls.
Instead, CallResolutionMode is introduced that is only used for
`transformFunctionCallInternal` call sites.
- Move it out of the ContextDependent hierarchy
- Get rid of many controversial checks that were necessary because
Delegate was a ContextDependent inheritor
- Actually fix semantics for lambda processing
Previously, lambdas as delegate expression were not being analyzed
thus leading to an exception (see KT-64635), and this change
forces analyzing them in the same mode as ContextIndependent
(thus `{}` made by default `() -> Unit` leaving to DELEGATE_SPECIAL_FUNCTION_MISSING)
Before this change, new test was failing with an exception.
I've analyzed all `is ContextDependent` and it seems that none of them
is relevant to delegates.
^KT-64635 Fixed
K2 version runs like for 15s.
It became slow after PCLA (KT-59791) was implemented,
and the reasons for that is the presence of a lot of interconnected TV
which leads to O(NUMBER_OF_CONSTRAINTS*NUMBER_OF_VARIABLES)
asymptotic during constraint incorporation.
The test itself in any way doesn't represent some common BI use case,
so it seems reasonable to mute it temporary.
^KT-65005 Related
See callingOuterGenericClassConstructorWithSelfTypes.kt
Previously, for A<B>(""), we used substituted constructor
where `X` was substituted with `B` (or `A<X>.B`).
But when resolving the call for constructor, we use `X`
as a type variable of the call, thus in some positions
we used `X` as TV (Xv in the comments) and somewhere `X` as a type
parameter, thus leading to contradictions (see clarifying comment).
The idea of the fix is simply repeating of the regular (not delegated)
constructor call resolution:
- We substitute only type parameters of outer class
- All the declared parameters of the callee are being checked
through regular resolution & inference mechanisms.
NB: Diagnostic only being reported on arguments because there
when we add `String <: Any` constraint it fails due to existing
contradiction in the CS.
Without the argument/parameter the error is just being lost, but that's
a different story (seeKT-65224).
^KT-64841 Fixed
While reporting a diagnostic there seems to be correct because the
parameter type is ConeErrorType, the former fact is a bug
in PCLA that should be fixed soon
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
It's expected to partially mimic the behavior of what
previously was called builder inference, but with more clear contracts
(documentation is in progress, though)
See a lot of fixed issues in the later commits with test data,
especially [red-to-green]
^KT-59791 In Progress
Instead, use specific resolution mode handled by call completer.
Mostly, it's done for simplification of PCLA implementation because
otherwise we would need to track how PCLA inference session and the
one for augmented should be combined.
But just independently of this, not using inference session here,
it looks just simpler.
^KT-59791 In Progress
Initially, it was a bug caused by unfortunate copy-paste, but there were
no tests for this because mostly `delegation` operators are functions
But after PCLA is implemented, many tests start failing
For example, FirPsiOldFrontendDiagnosticsTestGenerated.Tests.BuilderInference.OneParameter.OneTypeVariable.OneTypeInfoOrigin.TypeInfoSinks.testImmutableProperties
^KT-59791 In Progress
The test starts failing after switching to 2.0 because we don't support
TypeInferenceOnCallsWithSelfTypes though it's planned (see KT-59012).
This particular test was introduced in 1.5.x (see KT-48026) to check
if the flag -Xself-upper-bound-inference actually enables
the feature TypeInferenceOnCallsWithSelfTypes.
While the feature is enabled by default since 1.6, it doesn't make sense
to have it with earlier versions.
Another solution would be removing it at all, but that might require
removing related code as well (as we would have some dead code in CLI
arguments processing).
^KT-60885 Fixed
See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
It's been changed because `getValue` might be not completed after
exiting from call transformation while contracts processing seems to be
working only with completed calls
^KT-61055 Related
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
Currently, for other synthetic properties, deprecation from the original
method is already being propagated to the relevant new synthetic
property accessor.
But what we need is also reporting warnings on synthetic properties
accessors call-sites if original methods are considered deprecated
as a result of deprecation propagation.
KT-60659 Fixed
^KT-60769 Fixed
- Make addFirst/Last and removeFirst/removeLast as members
- Leave getFirst/getLast unprocessed, thus visible for K1, but marked
as deprecated
Though the implementations of getFirst/getLast and synthetic property
access to them are expected to be deprecated as well, it's expected
to be fixed in later commits.
^KT-60659 In Progress
^KT-60769 In Progress
Previously, it was reported for List.toArray because, when traversing
supertypes, we've been stopped at j.u.SequencedCollection
as it has no JavaAnalogue.
^KT-60770 Fixed
WithExpectedType mode was only needed to replace return type for the
getter, so I made it explicit there
After that, `resolutionMode` in `transformFunctionWithGivenSignature`
became effectively constant
Namely, in the previous commit we merged two
(LOW and HIGH priority default start import scopes) into the single one
For more explanations, please look at the previous commit
In K1 (see LazyImportScope), default start import with different
priority worked as follows:
- if something is found in HIGH, don't look at LOW
- otherwise, look at LOW
That, in particular, helped to avoid looking into JDK mirroring classes'
constructors like when resolving calls like String(...) because we
just don't look into j.l.String while already found kotlin.String
The change inside FirTowerResolveTask.kt is not made accidentally:
- At first, it's more or less obviously a bug fix because tower group
for hide-members candidate with implicit receiver should take into
account the tower level of the receiver itself.
- The change is attached to this commit because otherwise the test
at compiler/testData/diagnostics/testsWithStdLib/kt55503.kt starts
failing.
The bug was hidden because previously after finding a successful
`Sequence.forEach` candidate for the inner receiver
(at the default HIGH star import scope), resolver was continuing to
look into default LOW star import scope where it's frozen forever because
we had the better/closer candidate anyway.
But after this change with merging default star imports into the same
tower leve, resolver was continuing its job, enumerating implicit
receivers, finding List<Int> there and noticing that there's
a TopPrioritized hide-member candidates for them
(erroneously ignoring it has a worse/more far receiver).
^KT-51670 Fixed
The reason is that it's potentially might lead to some errors
are actually ignored leading to false-negatively green code,
while on the other hand we don't have any evidences (like tests)
that not-having the parameter lead to at least some redundant diagnostics.
- At first, get rid of a kind of interceptTowerGroup callback and use
explicit towerGroup construction instead
- Get rid of INVOKE_RECEIVER (not sure exactly why it was needed)
- Make comparison consistent with tower-levels priority of K2
(see the comments in the compareTo code)
^KT-37375 Fixed
^KT-58940 Open
The problem is actually caused by 60f09f6512
It happened because we've been caching package scope using FqName key,
so once one file contains aliased import it would work like other file
contains it, too.
So, the fix is adding excludedNames to the key, too.
^KT-59789 Fixed
Namely, once a file in a package `foo` has import `foo.bar as baz`,
auto imported `bar` from the package name becomes inivisible in the file
^KT-54854 Fixed
See the test data.
ISE happened because at some point after incomplete `getValue` resolution
of `a` property, we updated in the `transformAccessors` the property type
to the `Variable(Y)` type and then used it as a 3rd argument for
`setValue` call which is incorrect because the variable belongs
to a different constraint system (from `getValue`).
Mostly, the fix is just a repeating K1 behavior, namely postponing
`setValue` resolution until delegate inference is completed.
^KT-59066 Fixed
See 2e5b783cc6 for details
After the fix for KT-57694 (mostly rewritten JvmMappedScope),
the behavior of loading new JDK 21 members of K2 has been aligned with K1
It was happening because for MyClass.foo we didn't set overriddenSymbols
properly because in ClassMemberGenerator.convertFunctionContent we
used incorrect containingFirClass that was pointing to anonymous class
instead of MyClass.
^KT-58902 Fixed
Previously, it was led to plainly adding NullableType <: T constraint
which silently led to successful call completion.
What is suggested is just marking such initial constraint
as unsuccessful.
In K1, the error was reported just via additional type checking
mechanism being run after call completion.
^KT-58665 Fixed
Thus, KT-55586 is being postponed, too.
The reasoning behind this change is that the language-committee issue
has not been approved yet, so new annotation package can't be enabled
by default, but it seems that it doesn't make sense having
a different behavior for the old one but at least that would make them
work consistently, so we postpone them, too.
JvmMappedScope.Signatures became mostly irrelevant and only
"useful" for checking if we really need to have the scope mapped
Now, the check is rewritten according to K1 semantics
^KT-57694 Fixed
This change is both makes code more consistent with K1 version
and fixes some issues introduced by previous changes
Before this fix, the test
FirPsiOldFrontendDiagnosticsTestGenerated$Tests$Modifiers$Const.testKCallable_after
was failing
^KT-57694 In Progress
Earlier, it wasn't really important but after the previous commit
when JvmMappedScope semantics has been changed, we erroneously
started loading `toCharArray` as a member to String because
its jvmDescriptor was computed to "toCharArray()Lkotlin/CharArray",
while hardcoded information that prevents it from loading expect
"toCharArray()[C" there.
^KT-57694 In progress
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
After it's released, there would be no need in them, but right now
they are unavailable through the toolchain, so we can't require it.
See KT-58765 for tracking
But there should be a dedicated Build configuration with JDK_21_0 env
properly set.
^KT-58716 Fixed
So, we're slowly getting rid of the hack with LATE_JDK_SIGNATURES
which is necessary because there's no freshest JDK available at
build agents.
But hope, it would be removed once JDK 21 is there (see KT-58716).
Denis.Zharkov