Inferred type of receiver of orElse is Optional<T & Any>
Generic descriptor is orElse(E!): E!
Substituted descriptor is orElse(T): T , and that is the problem.
Seems that E! => (T & Any)! gets expanded to just T or T & Any , however it should be expanded to
(T & Any) .. (T & Any)? => T & Any .. T & Any
T & Any is NotNullTypeParameter(T)
The problem is that (T & Any)? is expanded to T & Any,
that is seems to be wrong.
#KT-15236 Fixed
- calls must be prohibited iff they refer to some additonal built in member
- override must be prohibited iff all of the overridden descriptors are additional
Other usages were able to be successfully compiled by 1.0.x
Solution with @Deprecated(level=Error) doesn't work properly, because
deprecation propagates to overridden, thus call 'java.util.ArrayList<String>().stream()'
becomes invalid, while it was correct in 1.0.x
#KT-15794 Fixed
This is needed because 1.1.2 binaries are considered pre-release (see
DeserializedDescriptorResolver), so it wasn't possible to compile
non-pre-release binaries with -language-version 1.0
The -Xskip-metadata-version-check command line argument is supposed to be used
to avoid getting errors only; the side effect that it also caused compiler to
write the pre-release flag to binaries was a mistake and is fixed now
We made it because of non-stable name resolution when project is multi platform. For such projects in platform module we have two classifiers with the same name, but impl class or type alias should win!
Metadata version is 1.1.2 since the start of Kotlin 1.1 EAP. Because the
pre-release flag was not written to class files compiled with 1.1 EAP, there's
no other way to figure out that they're pre-release except than to look at the
metadata version. This assumes that the version will be advanced to 1.1.3 once
Kotlin 1.1 is released
Catch all exceptions when deserializing metadata with an incompatible version
to prevent the compiler from failing on discovering incompatible classes on the
classpath. Note that this is not the perfect solution: any invariant may be
broken in the incompatible metadata and it may result in a later exception
Similarly to pre-release classes, load metadata for the class anyway and allow
the resolution to select it as the result and prohibit its usage in the end
with the special diagnostic reported in MissingDependencyClassChecker
Extract AbstractDeserializedPackageFragmentProvider out of
JvmBuiltInsPackageFragmentProvider and implement it a little bit differently in
MetadataPackageFragmentProvider. The main difference is in how the package
fragment scope is constructed: for built-ins, it's just a single scope that
loads everything from one protobuf message. For metadata, package scope can
consist of many files, some of which store information about classes and others
are similar to package parts on JVM, so a ChainedMemberScope instance is
created.
Introduce a bunch of interfaces/methods to deliver the needed behavior to the
'deserialization' module which is not JVM-specific and does not depend on the
compiler code: MetadataFinderFactory,
PackagePartProvider#findMetadataPackageParts, KotlinMetadataFinder#findMetadata.
Note that these declarations are currently only implemented in the compiler; no
metadata package parts/fragments will be found in IDE or reflection
Compilation of top level functions/properties/typealiases results in a bunch of
different .kotlin_metadata files, so we need to store names of these files to
avoid scanning the file system in the compiler when loading code compiled by
K2MetadataCompiler.
For this, we reuse the PackageTable protobuf message, which is already used for
exactly the same purpose in the JVM back-end
Provide a command-line option to load built-ins from the module and its
dependencies instead of looking for them in kotlin-compiler.jar; built-ins must
be found this way, or an error will be reported (or, most likely at this
moment, an exception will be thrown).
Note that this does not affect whether built-ins (loaded from one place or the
other) are added to the _dependencies_ of the module, this is controlled by
another option. The option added in this commit only makes the KotlinBuiltIns
instance which is used via ModuleDescriptor throughout the compiler front-end
(and also injected in a bunch of places) a sort of "helper" which always goes
to that same module to find descriptors for built-in classes
Alexander Udalov