This commit support the following case.
Suppose we have such declaration:
fun <T> foo(): T { ... }
Then in code we want to use it like this: `foo() as String`.
But in LV <= 1.1 we have type inference error: "Not enough
information for type parameter `T`". This error happened because we
do not use type from cast as expected type for call.
In this commit we fix this problem and use this type as expected type
in following cases:
- our function has only one type parameter (this can be relaxed later)
- function parameter types and extension receiver type not contains `T`
Also this fix problem with `findViewById`.
Already signature was: `fun findViewById(...): View`
and was used like: `findViewById() as MyView`.
New signature is `fun <T : View> findViewById(...): T`
and old usage was broken because of problem described above
This flag is used internally by EffectSystem as a sign of compiling
stdlib. If this flag is present, then EffectSystem will read contracts
on functions and serialize them into metadata even if corresponding
LanguageFeatures are turned off. This is done solely for building
1.2-runtime with contracts in it without the need to turn on
LanguageFeatures manually.
======
This commit finishes a first series of commits related to effect
system. After it, compiler is ready to work with contracts, but it is
impossible to actually annotate anything, because there are no
contracts DSL in stdlib yet.
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.
Do it in the same way as Java: prohibit inner classes (including
anonymous inner classes) capturing type parameters from outer classes
(but not outer methods) extending Throwable.
See KT-17981:
- Deprecated in 1.2
- Error in 1.3
Instead, rework the (already suspicious) KotlinPaths-finding code in
PathUtil to support the new model of running tests (the compiler is
split into several jars according to the project structure) instead of
the old one (where class files were not in the jars, but in the out/
directory).
This fixes Java9ModulesIntegrationTest
LanguageVersionSettings doesn't mean that the module is actually
multiplatform; it only means that it _could_ be one. Use
platform and information from facet instead.
Also fix detection of common stdlib version and add tests for common
run config.
Synthesized 'copy' introduces default values for parameters, which is
prohibited for regular overrides.
Report warning in language version 1.2-, error in 1.3+.
In Kotlin 1.1 and before, there were no nullability assertions on
extension receivers, because receiver is resolved with NO_EXPECTED_TYPE.
So, if an expression of platform type is passed as an extension receiver
to a non-private function, it would fail with IllegalArgumentException.
However, if the function is private, then we generated no parameter
assertions under assumption that such function can be called from Kotlin
only, and all arguments are checked on the call site. Thus 'null' could
propagate indefinitely.
In Kotlin 1.2, we do the following:
- Generate nullability assertions for expression receivers.
NB nullability assertions are stored for ReceiverValue instances, not
for expressions: given expression can act as receiver in different
calls, each with an expected receiver type of its own.
- Generate nullability assertions for extension receivers of private
operator functions.
NB it still can throw NPE for some particular "optimized" cases, but at
least those nulls would not propagate indefinitely.
This behavior is disabled by an "advanced" command-line option
'-Xno-receiver-assertions'.
Dmitry Petrov