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
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
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
It's disposed after Disposer.dispose(myTestRootDisposable) in tearDown and mixing compiler tests
with non-compiler tests may ruin classes initialization with
"com.intellij.util.IncorrectOperationException: Sorry but parent: com.intellij.mock.MockApplicationEx@52439591 has already been disposed"
(cherry picked from commit f3badb6)
Do not run annotation resolver tests on lambda parameters,
mostly because it's impossible to annotate them by now
(see KT-13900 and `val functionLiteral` in compiler/testData/resolveAnnotations/testFile.kt)
It was working before only because lambda parameter hadn't been parsed at all,
while after introduction of destructuring in lambda parameters
it gets parsed normally
#KT-13900 Submitted
- remove Future from resovler since the idea need additional considerations
- simplify script contents interface
-extend script dependencies with additional javaHome property
- return Future from resovler
- pack script contents data to a separate interface
-extend script dependencies with additional scripts property
- minor renames and moves