In AbstractPositionManagerTest, built-ins could no longer be resolved because
JvmIDEVirtualFileFinder is used in IDE tests (even when the compilation is
called through JvmResolveUtil/GenerationUtils as in compiler tests), which is
not yet able to locate .kotlin_builtins files
- In tests on built-ins with no sources, just call
JvmResolve.analyze(environment) and inspect the resulting module
- In AbstractLocalClassProtoTest, create container via
TDAForJVM.createContainer
- Inline single module container creation into AbstractDiagnosticsTest
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)
Ilya Gorbunov