A class can inherit two declarations that are compatible from the
overridability standpoint and are therefore combined to a non-trivial
intersection.
At the same time, the class can declare a member declaration that
only overrides one of the intersection's members.
In this case, we break up the intersection and only add the overridden
parts to the declared member's direct overridden list.
If the class doesn't override the intersection, it exists as
intersection override, like before.
#KT-65487 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
Even though SO may not be correct
overrides sometimes, it feels more
natural to treat fake overrides as...
well, "overrides". And without it
we'd need to make the code in
`FirOverrideChecker` less intuitive.
Make parcelize work consistently with
`FirOverrideChecker`.
Actually, there is a philosophical question about
what to do when a plugin generates a class
in a new package, and this class is red code
(for instance, doesn't implement an abstract
member from a supertype). There's no source
to report such an error, but we probably do
want to run checkers to avoid trying to
compile red code to binaries (because it may
crash in backend, or it may silently work).
In general, overrides should not
contain default values, and it's
better to make fake overrides be close
to proper overrides as much as
possible. It will be important when
we begin running `FirOverrideChecker`
for fake overrides.
^KT-63879 Fixed
^KT-65534
Partially reverts 24367e0ad8
Constructors have their own list of hidden/visible.
We now require the constructor to be in VISIBLE_CONSTRUCTOR_SIGNATURES,
everything else is hidden.
This makes it unnecessary to check HIDDEN_CONSTRUCTOR_SIGNATURES
#KT-65821 Fixed
Previously we forced computation only for java and precompiled classes,
assuming, that binary class can not extend source class, but it's not
true in two cases:
1. Classpath substitution: class with same name declared in library and
the source (more rare case)
2. Metadata compilation: depends-on dependcies are passed in binary
format, so `expect class` may be a binary one and corresponding
`actual class` may be a source. So if some class in `common` module
extend this expect class, actual class will be substituted instead of it
^KT-65669 Fixed
Dmitriy Novozhilov