In general case, the module where built-ins are looked up
(builtInsModule) can have multiple package fragments corresponding to
the package "kotlin". Remove the misleading method
getBuiltInsPackageFragment along with its implementation details and use
the package view's scope instead (by changing
KotlinBuiltIns.getBuiltInsPackageScope), since it'll iterate over all
fragments accessible in the module and its dependencies.
The only difference between scopes of package fragment and package view
is that the latter also contains package views for subpackages, which is
why the change in BuiltInsReferenceResolverTest is necessary
Default built-ins represent built-ins loaded from the compiler jar via
class loader, and they may not be equivalent to the built-ins present in
the standard library that is used in compilation dependencies, in case
the compiler and stdlib versions do not match. Use built-ins from the
given module instead.
This commit deals with more-or-less obvious usages of DefaultBuiltIns;
next commits refactor the ESConstant values and related code to support
injected built-ins
Instead use a filter with a simple check. This seems to be slightly
better both for readability (`strictPartition` gave an impression that
two its parameters were related in some way, but they were totally
independent) and for performance (do not create unnecessary objects,
instead decompose the existing objects and check their structure)
Simplify MultifileClassPartCodegen, remove related tests and change some
tests to use const val instead of val because backing fields for const
properties are stored in the facade, not parts
#KT-23701 Fixed
In JDK 9, Class.simpleName changed behavior for local/anonymous Kotlin
classes (see KT-23072), this is why we now check for both variants of
the name in tests. Also, the format of annotation arguments changed a
little, where float parameters no longer have the trailing "f", and
class literals are rendered with ".class" at the end
Bypass builtins deserialization mechanism in legacy JS backend and load
bultins direcly as kotlin code.
This way we won't have separated IR declarations for Enum, Char, Long
Some "native" builtins are implemented in libraries/stdlib/js/irRuntime/builtins/
Other builtins are moved by MoveExternalDeclarationsToSeparatePlace and
used only in compile-time
Now both of those classes implements one interface with `TypeProjection`
property. That allows old captured type approximator use new captured types.
That change fixes tests related to diagnostics:
- SETTER_PROJECTED_OUT
- DEBUG_INFO_UNRESOLVED_WITH_TARGET
- UNRESOLVED_REFERENCE_WRONG_RECEIVER
Also `typeProjection` property renamed to `projection` according to naming in NI.
That commit fix next diagnostics:
* RECEIVER_NULLABILITY_MISMATCH_BASED_ON_JAVA_ANNOTATIONS
* NULLABILITY_MISMATCH_BASED_ON_JAVA_ANNOTATIONS (partially, see #KT-29367)
Simplify ifs when branches have condition true/false.
Simplify blocks containing only a variable declaration
and a variable get of the same variable. Simplify to
just the condition.
Do not introduce temporary variables for constants for
null checks. Constants have no side-effects and can be
reloaded freely instead of going through a local.
This simplifies code such as "42.toLong()!!" so that the
resulting code has no branches and uses no locals. The
simplifications happen as follows:
```
block
temp = 42.toLong()
when
(temp == null) throw NPE
(true) load temp
---> null test simplification
block
temp = 42.toLong()
when
(false) throw NPE
(true) load temp
---> when simplification
block
temp = 42.toLong()
load temp
---> block simplification
42.toLong()
```
* if enum class has abstract members, then it is ABSTRACT
* otherwise, if enum class has entries with members, then it is OPEN
* otherwise, it is FINAL.
In case of the same class defined in different modules they contain
different descriptors instances in their scope that might lead
to failing assertion in findConcreteSuperDeclaration
because there are overridden from different modules
It might happen even in the compiler because of different built-in modules
defined for sources-module and for dependencies' one
^KT-29320 Fixed
On windows using a project's root
as a working directory for the daemon
seems to prevent removing the directory
when the daemon runs.
Different projects may share an instance of the daemon,
so the issue will be present only in a project
which started the daemon.
Alexander Udalov