Introdude deprecation as per KT-21515. Warning is reported on type
usage, that soon will became invisible. Quickfix by adding explicit
import is added.
Idea behind implementation is to mark scopes that are deprecated (see
ClassResolutionScopesSupport).
Then, during walk along hierarchy of scopes, look at deprecation status
of the scope that has provided this classifier.
Note that we also have to check if there are *some* non-deprecated
visibility paths (because we can see classifier by two paths, e.g. if
we've added explicit import) -- then this type reference shouldn't be
treated as deprecated.
- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
According to KT-21354, this should be a warning in 1.2 and before, and
no warning (with changed semantics) in 1.3 and later.
NB there are some false positives in this check.
#KT-21354 In Progress
#KT-21321 In Progress
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
Alexander Udalov