Before this commit, the substituted FunctionDescriptor didn't have a source element.
As a result, 'CodeFragmentParameterAnalyzer.isCodeFragmentDeclaration' failed to recognize such a descriptor as fragment-local, and it was erroneously captured.
Private-in-file declarations conflict with public overload-equivalent declarations
in other files in the same package.
Move functions for grouping possible redeclarations to OverloadResolver
(since they are used only there).
Refactor redeclarations / conflicting overloads reporting.
There is no need to report an error in case of non-top-level
capture conversion, just don't add relevant capture type in the system instead
If system can be solved successfully without captured type, then it's just fine
(see KT-13950)
In case of contradiction TYPE_INFERENCE_PARAMETER_CONSTRAINT_ERROR is reported
#KT-13950 Fixed
Clients of the call resolution do not expect to see a throwing list in call's
arguments, and it's wrong to make each of them check against the special case
that is the resolution of callable references
Fixes EA-69901
Skip declarations without sources in reporting, not when determining redeclaration groups:
this allows emitting informative diagnostics for incremental compilation.
Provide containing declaration with "kind", e.g., "package '<root>'", "class A", and so on.
When checking for overloads in package, consider functions and top-level class constructors as possibly conflicting between each other. NB OverloadUtil uses containing package scope from module descriptor.
Change diagnostic message for CONFLICTING_OVERLOAD: it's misleading in case of fun vs constructor conflict.
Add custom multifile test for diagnostics in IDE (probably not the best; should preprocess file content if it's required to check highlighting in multiple files, not only in the first file).
Add test for KT-10765 Incremental compilation misses overload conflict between constructor and function ...
- 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
- base class method wins against a (default) interface method,
so an abstract base class method should always be implemented
in a derived class;
- interface methods clash regardless of abstract/default
with possibly undefined behavior at run-time,
so a class or interface should always define its own method
for methods inherited from multiple interfaces and not from base class;
- meaningful diagnostics for class inheriting conflicting JVM signatures.
Since no override will happen under Java 8 rules,
ACCIDENTAL_OVERRIDE is misleading for this case;
- update testData.
It's done with similar constructions where possible trying to preserve
intended behavior.
Some usages are removed because they test exactly the feature that
we are going to drop soon.
Pavel Kirpichenkov