If there are some other completion-like tests before these ones
it may lead to the situation when some value is already written by
`previouslySuggestedExpressions`, so it should be cleared in setUp
To simplify migration from 1.0 to 1.1, do not allow data classes to
automatically implement abstract equals/hashCode/toString declared in
super-interfaces (KT-11306) if "-language-version 1.0" is specified
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 new settings checkCanBeUsedAsValue
Also expression filtering are split into to parts:
- getNonFilteredExpressions is trivially goes until it reaches
first block body of some declarations
- all additional filtering is merged into Condition that is passed into
PostfixTemplateExpressionSelectorBase super-call
Notable changes for users:
- do not suggest try for non-top-level expressions
- do not suggest var/par/etc for loops
Unless the compatibility option "-Xsingle-module" is passed, the compiler will
create two modules instead of one now (see TopDownAnalyzerFacadeForJVM): the
main module contains Kotlin and Java sources and binaries from the previous
compilation of the given module chunk, the dependency module contains all other
Kotlin and Java binaries. This fixes some issues where the compiler couldn't
detect that the used symbol was from another module, and did not forbid some
usages which are only possible inside the module (see KT-10001).
The ideal way to deal with modules here would be to exactly recreate the
project structure, for example as it's done in JvmAnalyzerFacade and usages.
This is postponed until later
#KT-10001 Fixed
#KT-11840 In Progress
This is needed because otherwise with separate modules turned on in the
compiler, these tests do not display the contents of classes from the
dependency module in the rendered output
Currently behavior is unchanged because the "all project" scope is passed,
however in the future this will allow to implement separate modules in the
compiler properly
- Document what exactly should findPackageParts return
- Make EMPTY a named object instead of a val in the companion
- Do not use JvmPackagePartProvider in tests where Empty works fine
- Add a couple default values to arguments of setupResolverForProject
Filtering out obsolete package parts in incremental compilation was necessary
before the big refactoring of package parts, when package parts had been
compiled together into a package class
If a module is configured in such a way that the same function appears multiple
times via different dependencies, it's not helpful to report "none of the
following functions can be called", listing the same function multiple times
Add an assertion to prevent duplicate initialization of CodegenTestFiles
instance in CodegenTestCase, which was happening in ScriptGenTest with multiple
invocation of loadFile()
The only place where the logic has changed is in AbstractDiagnosticsTest, where
modules are already created and sealed before the analysis. Copy-paste the
container creation logic there (it's almost fine because it's also present in a
bunch of other tests), and simplify it: get rid of incremental compilation and
other stuff irrelevant for diagnostic tests.
This is needed to make analyzeFilesWithJavaIntegration configure the module
properly before sealing it
Dmitry Jemerov