Consider following case:
fun foo(): Unit = run { "hello" }
Previously, NI would analyze lambda body without expected type, because
it is a type variable 'R' from 'run', which hasn't been fixed yet. This
leads to treating "hello" as lambda-return argument and adding bogus
'String' constraint on 'R', and, consequently, type mismatch.
Now, we peek into current constraint system and check if return-type of
lambda is type variable with upper-Unit constraint (which is exactly
condition for its body to be Unit-coerced). If so, then we provide
expected Unit-type for body explicitly, and the rest will be done
automatically (in particular, in aforementioned example "hello" wouldn't
be treated as lambda return argument).
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.
Ilya Chernikov