- `toolWindowHandler` would be shared between different scratch editors, so we need `ScratchToolWindowHandlerKeeper` to provide proper mechanism for its acquiring and releasing
- fix problem when scratch output panel is never released after first scratch opening by properly unregistering `toolWindow` with `ToolWindowManager`
- get rid of `ScratchFileHook` completely
- use `KtsScratchFileEditorProvider` to encapsulate details about scratch file presentation
- remove obsolete functions from `scratchUtils`
- with `FileEditorManagerTestCase` it is possible to work with actual TextEditors instead of wrappers during tests, so it will be possible to use `TextEditorWithPreview` via `TextEditorProvider` service
- remove `getOutputHandler` method from `KtScratchFileLanguageProvider`
- now `InlayScratchOutputHandler` is a class, it has reference to the target editor and is (temporarily) attached to the editor
- migrate module to the `ScratchPanel` class because it is information that matters to him most of all
- move logic for showing\hiding checkboxes to the related actions
There are two parts in this change:
1) Previously, we looked up $default methods with the incorrect
signature in supertypes. For example in defaultInSuperClass.kt, we'd
try to find a method foo$default with the signature `(B, String,
String, int, Object)` in the class A. Now we're modifying the array
of parameter types on each step if we're looking for a static
$default method, by assigning its first element to be the containing
class. This fixes cases when defaults come from a superclass.
2) For interfaces, $default methods are actually located in the
corresponding DefaultImpls class. Now we look up that class and
search for the $default method there. Note that this is needed
because of KT-33430. This fixes cases when defaults come from a
superinterface.
#KT-13936 Fixed
Add directory libraries/stdlib/wasm as a placeholder for WASM runtime library
Copy built-ins from core/builtins
Add ExcludeFromCodegen annotation for internal needs
When instantiating annotation processors, the class loader where they
are defined needs to have the correct parent class loader set up. In
order to find the parent class loader, we need to find the most specific
class loader that contains javac compiler classes (and does not contain
e.g. KAPT classes). This commit changes how that search is done, and it
simply returns the class loader in which the com.sun.tools.javac.util.Context
is defined, as the is the class we need on the annotation processor
classpath.
This commit fixes KT-33028 by not setting empty boot classpath when
running on JDK9+. When compiling with -source 8 and below, this allows
classes from java.base module to be available in the boot classpath.
This commit also fixes KT-33050 by passing the source level of Java compile
task in the KAPT javac options. This is important as some annotation processors
are using ProcessingEnvironment.getSourceVersion() in order to decide what
code to generate.
Test: Kapt3IT test added for worker and non-worker invocations
Roman Golyshev