Forbid underscore-only (_, __, ___, ...) names as callees and as types.
If CHECK_TYPE directive is on, filter out UNDERSCORE_USAGE_WITHOUT_BACKTICKS messages.
Types of the corresponding parameters (or type parameter bounds, types
in supertypes, etc) are now compatible not only if they're equal, but
also if values of those types are mutually assignable (if "a" is subtype
of "b" and "b" is subtype of "a")
#KT-17005 Fixed
Fix CCE on callable references to Java methods.
Fix qualification of callable references without receivers.
Fix processing of calls/callable references to object extensions
and extension members.
Do not explicate short companion references
#KT-16809 Fixed
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
Previously, type substitution, which is critical for matching generic
header/impl members with each other, was only performed when
checkImplementationHasHeaderDeclaration was called for impl class
(areCompatibleClassifiers creates the correct substitutor). This was
done in areCompatibleClassifiers: a substitutor which maps type
parameters of the header class to type parameters of the impl class was
created.
Now we create the same substitutor when
checkImplementationHasHeaderDeclaration is called for an impl member of
an impl class as well, manually.
#KT-15230 Fixed
Similarly to getFirstClassifierDiscriminateHeaders, we select the first
non-header class if possible, otherwise we select just the first class.
This makes sure that a reference will never be resolved to a header
class if the corresponding impl class is present.
Note that overall the issue may not be fixed yet, because there are
other scopes where header classes are not yet discriminated
(LazyImportScope, DeserializedMemberScope). However, at this point I
cannot reproduce this problem with these other scopes
#KT-15521 Fixed
Currently this is achieved with several hacks:
- Postpone computation of argument type info when there is no candidate resolver. We have to do this, because we don't have expected type and therefore we could write wrong information to trace
- Presume that for annotation calls there is only one candidate resolver and then resolve arguments with expected type (see `getArgumentTypeInfo`), otherwise because of quadratic complexity of the algorithm resolve would be slow
allows to compile only parts of the source files, denoted by top-level
"sections" (function with lambda param calls), but preserving original
file line/column numbers for easier diagnostics. Allow e.g. to compile
gradle "buildscript" section without preprocessing original file in
advance. See tests for examples.
Lexer monitors "long string template" state end and will produce
LONG_TEMPLATE_ENTRY_END token when it is reached. If parser continues
without waiting for it, it will eventually get handling token that
will produce irrelevant error. Such behaviour also breaks lazy
elements (LAMBDA_EXPRESSION in this case) contract: range of parsed text
in eager mode should be same to one parsed in lazy mode.
#KT-14865 Fixed
Some IDE features relates onto that same descriptors will remain same
between resolve calls
Fix it to be true for TypeAliasConstructorDescriptor's
#KT-16265 fixed
Mikhail Zarechenskiy