In 1.3, due to changes in language, testdata for some tests can be
different from 1.2
We want to simlultaneously test both versions, so instead of fixing
language version in such tests, we split them into two: one with fixed
1.2, another with fixed 1.3
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.
In most of the cases it was used together with CLASS_ONLY and vice versa
They only case when CLASS_ONLY was used without INNER_CLASS
is possibleParentTargetMap.COMPANION_KEYWORD.
But after diagnostic NESTED_OBJECT_NOT_ALLOWED has been introduced,
there's no sense in the restriction of exactly the companion's parent
For clarification see test data changed
- locals win
- unary calls to plus/minus are not supported in favor of unaryPlus/unaryMinus
- unqualified nested classes are temporarily reported as unresolved
- function without receiver win against extension function
- explicit import win against star import
This became necessary when we removed the requirement to specify types for
public members, because otherwise everything fails not being able to locate the
anonymous class from another module
#KT-9072 Fixed
EA-72801
Most of modifier diagnostic is expressed by REDUNDANT_MODIFIER, INCOMPATIBLE_MODIFIERS, REPEATED_MODIFIER, WRONG_MODIFIER_TARGET, WRONG_MODIFIER_PARENT.
A set of modifier diagnostics is not in use now (but not deleted yet).
victor.petukhov