This commit introduces proper handling of recursion in scopes, which
could occur when some of companion object supertypes are members of
that companion owner:
```
class Container {
open class Base
companion object : Base()
}
```
To resolve `Base`, we have to build member scope for `Container`.
In the member scope of `Container`, we see all classifiers from
companion and his supertypes
So, we have to resolve companion objects supertype, which happens to be
`Base` again - therefore, we encounter recursion here.
Previously, we created `ThrowingLexicalScope` for such recursive calls,
but didn't checked for loop explicitly, which lead to a wide variety of
bugs (see https://jetbrains.quip.com/dc5aABhZoaQY and KT-10532).
To report such cyclic declarations properly, we first change
`ThrowingLexicalScope` to `ErrorLexicalScope` -- the main difference is
that latter doesn't throws ISE when someone tries to resolve type in it,
allowing us to report error instead of crashing with exception.
Then, we add additional fake edge in supertypes graph (from
host-class to companion object) which allows us to piggyback on existing
supertypes loops detection mechanism, and report such cycles for user.
Use words 'returnArgument' instead of 'resultArgument' when talking
about values, which can be possibly returned from lambda.
Correct 'addSubsystemForArgument' -> 'addSubsystemFromArgument'
Previously, we did approximation of error types to Any?/Nothing in some
contexts (e.g. non-local declarations).
There are several reasons why it is not desired:
- OI doesn't approximate ErrorType
- This behaviour is inconsistent with ourselves (i.e. sometimes we *do*
infer errortype for top-level declaration)
- It causes different digressions from OI in reported diagnostics
This commit turns off error type approximation. It causes large testdata
shift, which is deliberately split into several parts and commited in a
separate commits.
Previously, constraint wasn't added if bound was ErrorType. That could
cause TypeVariable to be inferred to Any?/Nothing instead of ErrorType,
which could influence other parts of analysis (in particular, inferring
Nothing instead of ErrorType can cause bogus UNREACHABLE_CODE diagnostics)
Because of that fix, intersection type can be added to CS as supertype,
which provokes AssertionError. This commit also relaxes this assertion,
as it seems that it's valid that supertype is an intersection type.
Check if ConstrainSystem has any contradiction in 'isSuccessful'.
Otherwise we may erroneously think that there are some successful
candidates in 'TowerResolver.SuccessfullResultCollector.pushCandidates()'
and clear other unsuccessful ones (while they actually may have higher
applicability).
Currently there are two major phases in NI that report diagnostics: resolution parts and completion. They connected in method `KotlinCallCompleter.runCompletion` and previously diagnostics were collected in several places, from resolution atoms, partly from constraint system and partly from `CallResolutionResult`, some of them were lost.
To mitigate this problem, now diagnostics are not bind to the intermediate candidate, only to the result resolution candidate (overloaded or usual one). And all diagnostics are now collected in method `runCompletion`
If expected type is a type variable, then we'll wait for proper constraints, but previously we resolved callable reference as it didn't have expected type at all, because type variable isn't a functional type
Consider the following example:
fun foo(i: Int) {}
fun foo(s: String) {}
fun <T> id(x: T): T = x
fun test() {
val x1: (Int) -> Unit = id(id(::foo))
}
Here we shouldn't resolve callable reference until we get constraint from expected type of `x1`
Expect members should always lose in resolution to non-expect members,
be it simple calls or callable references. Note that there should be
exactly one actual member for each expect member in correct code, so
both ways to check for expect vs non-expect are correct: either before
signature comparison, or after.
#KT-20903 Fixed
- Add ContractDescriptorRenderer
- Add option to dump function contracts in DescriptorRendererOptions
- Add parsing of LANGUAGE_VERSION directive in AbstractLoadJava
- Add tests on serialization-deserializaton identity of contracts
==========
Introduction of EffectSystem: 13/18
- Introduce new definitions in descriptors.proto
- Add new corresponding values in Flags.java
- Introduce ContractSerializer and ContractDeserializer, responsible for
for conversion ContractDescription <-> ProtoBuf.Contract
- Add dependency of 'serialization' module on 'resolution' so that it
could see contracts model.
Note that here we do a lot of seemingly unnecessary hoops, which in fact
necessary to respect existing module system (in particular, to be able
to extract ContractDescription declarations from 'descriptors' module to
make them invisible from reflection)
==========
Effect System introduction: 8/18
Add model of contracts used by compiler during analysis. It should be
thought of as structure which used by the compiler to implement
semantics, expressed by the ContractDescription.
==========
Effect System introduction: 2/18
Add ContractDescription structure which is used for declarative representation
of function's contract.
Also, add corresponding LanguageFeatures.
==========
This is the first commit from a series of 18 commits which gradually
introduce effect system into the compiler. All such commits will be
marked with appropriate comment and index in that series.
While each one of such commits separately shouldn't break compiler (i.e
you can checkout any of them and expect compiler to build and pass
tests successfully, e.g. for bissecting purposes), semantically they
all are one big feature and not entirely independent. Please bear that
in mind while working with/changing only some of them -- some strange
effects can happen.
Its main purpose is code simplification: ImplicitScopeTower::run
contains a lot of local functions that are needed because of
lots of shared state
So, we're moving the state to the Task class instead
NB: This change doesn't change the code of `run`, it will be done
in further commits
The idea is that all tower levels are partitioned into two groups:
- ones that may contain the target name or INVOKE; they're processed as usual
- ones that can't contain the name; they're simply skipped until
the end of resolution process when it's being passed to scope processors
to allow them record necessary lookups
definitelyDoesNotContainName is called too eagerly sometimes and it leads
to obviously redundant lookups
The idea is to put responsibility for calling recordLookup to resolution
itself
Mikhail Zarechenskiy