Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
Previsously, errors have been ignored because we ignored errors raised
from the completion phase
See the comment above the createConstraintPartForLowerBoundAndFlexibleTypeVariable
Remove any logic related to finding the single parameter of the primary
constructor, and use inlineClassRepresentaton from IrClass or
ClassDescriptor instead.
This will be used at least in the JVM backend instead of the current
approach where we're loading the primary constructor's first parameter,
which isn't good enough since primary constructor can be private, and
we can't rely on private declarations in case they're declared in
another module.
In FE10-binding I would like to re-use equal and hashCode mechanics
that was implemented in AbstractTypeConstructor, but I don't need
the supertype implementation, because it already there in FIR
This method can be useful when overriding a throwing Kotlin method in
Swift or Obj-C. In this case, a user can call asError to wrap Kotlin exception
to (NS)Error and then throw it to Kotlin, which will unwrap it back.
^KT-45127 Fixed
This is needed to reuse EffectiveVisibility in FIR, because typeContext
in it is used to call `isSubtypeOf`, and in FIR it's required to use
context from use site session (to see all declaration which are
available in module)
KotlinTypeMapper.mapInlineClassTypeAsDeclaration and
mapUnderlyingTypeOfInlineClassType invoked mapType which is defined in
descriptorBasedTypeSignatureMapping.kt and works on KotlinType.
It didn't lead to any problems, other than the fact that we were
constructing IrBasedClassDescriptor in JVM IR, and then KotlinType to
pass it to mapType, on each call to StackValue.boxInlineClass or
unboxInlineClass, which seems wasteful.
Instead of this, refactor these utilities to use type markers instead,
pass IrType and IrTypeMapper directly from JVM IR, and move the "static
type mapper" logic (which is used only in the old backend) out of
KotlinTypeMapper.
Before this fix, if some imports were not resolved during compilation,
this result had been saved in caches, and this import couldn't been
resolved during following compilations even if it was added to the
module dependencies. This commit adds special handling of resolution
caches for the REPL compiler.
Victor Petukhov