This is an addition to c1ab08c8ce where KT-26582 was fixed. The test
testClassLiteralArguments in JvmRuntimeDescriptorLoaderTestGenerated
failed before this change but went unnoticed because it wasn't run on CI
(see the previous commit)
- Add marker for the experimental type inference features
- Add annotation that will control builder-like inference
- Require that annotation on corresponding parameters and extensions
- Allow to use builder inference without suspendability
Changes in tests and refactorings (rename mainly) are going to be
introduced in further commits
In MemberDeserializer.loadProperty, we incorrectly passed 0 to
getAnnotations when loading annotations on property accessors in case
the protobuf field getter_flags/setter_flags was not present. The
correct behavior, as described in metadata.proto, was to pass a special
"default accessor flags" value, constructed from the main property
flags. Otherwise in case there were annotations both on the property and
on the accessor (as in PropertyAndAccessor.kt) and the accessor was
otherwise default, we would assume that it had no annotations and would
not load them in compiler and reflection
#KT-25499 In Progress
The exception was incorrectly introduced in 0f0602230a. We should not
fail when `names` is null, only when there's no element at the
corresponding index. On Java 6, `names` is always null. On Java 8,
`names` is never null (it's an empty list if the class was compiled
without "-parameters")
PSI-based implementation (accessible via
`-Xuse-old-class-files-reading`) loads parameter names from the
"MethodParameters" attribute if it's present, so our own implementation
should as well.
This metadata doesn't seem supported in the java.lang.model.element API
though, so SymbolBasedValueParameter (which is used in `-Xuse-javac`)
will continue to have incorrect behavior for now
#KT-25193 Fixed
The issue was reproducible when the same package is present in different
modules with the same -module-name (which is a popular case of src/test
roots in simple IDEA projects). The problem was in the fact that several
resource files containing package name mapping with the same name were
present in the classpath, but RuntimePackagePartProvider only considered
the first one. The fix is to use getResources instead of
getResourceAsStream and handle each returned resource.
Also, optimize internal representation to store the mapping in the form
which is the most convenient for findPackageParts, which should be
faster than registerModule because in theory, it's called more often.
#KT-21973 Fixed
#KT-24651
There's still some blind spots:
- Covariant overrides in Java (KT-25036)
- Current implementation assumes that when language version is 1.3 every suspend function
reference only release-coroutines-package Continuation
(we need to check if it's a correct statement)
#KT-24848 Fixed
#KT-25036 Open
Introduce COMMON_COROUTINES_TEST directive.
Every test with this directive is run twice: one time with
language version 1.2 and kotlin.coroutines.experimental package
and the other time with language version 1.3 and kotlin.coroutines
package. Each run is a separate method: with suffixes _1_2 and _1_3
respectively.
However, since codegen of release coroutines is not supported in JS
backend, we generate only one method: with suffix _1_2.
#KT-23362
Also, fix the value of "hasAnnotations" flag to reflect if there are any
_non-source_ annotations on a declaration.
Unfortunately, after this change
IncrementalJsCompilerRunnerTestGenerated$PureKotlin.testAnnotations
starts to fail because of the following problem. The problem is that
annotations on property accessors are not serialized yet on JS (see
KT-14529), yet property proto message has setterFlags field which has
the hasAnnotations flag. Upon the full rebuild of the code in that test,
we correctly write hasAnnotations = true, but annotations themselves are
not serialized. After an incremental build, we deserialize property
setter descriptor, observe its Annotations object which happens to be an
instance of NonEmptyDeserializedAnnotationsWithPossibleTargets. Now,
because annotations itself are not serialized, that Annotations object
has no annotations, yet its isEmpty always returns false (see the code).
Everything worked correctly before the change because in
DescriptorSerializer.hasAnnotations, we used Annotations.isEmpty and the
result was the same in the full rebuild and in the incremental scenario.
But now we're actually loading annotations, to determine their
retention, and that's why the setterFlags are becoming different here
and the test fails
#KT-23360 Fixed
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Only require implementations to be able to compute the enum class name
and the corresponding entry name. Only this should be necessary to
correctly resolve the argument; the resolvers will find the
corresponding class descriptor if necessary
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
It's purpose is passing java classes being used during analysis
to incremental compilation to let it track diffs
Potentially it might be done the other way:
incremental compilation could build a separate container to analyze
necessary classes, but it's rather hard to implement now
#KT-17621 In Progress
This allows to get rid of the dependency on descriptors.runtime from
compiler/IDE tests which is problematic: classes there clash with the
classes in kotlin-reflect, which reference declarations in shadowed
packages
To make it obvious that this is a part of kotlin-reflect and should not
be packed into the compiler jar. Also copy 'classId' utility to
AbstractLocalClassProtoTest to minimize dependencies on
kotlin.reflect.jvm.internal
Note that the module itself is still needed and can't be merged into
kotlin-reflect because of the way it's used in
AbstractJvmRuntimeDescriptorLoaderTest
- Introduce new definitions in descriptors.proto
- Add new corresponding values in Flags.java
- Introduce ContractSerializer and ContractDeserializer, responsible for
for conversion ContractDescription <-> ProtoBuf.Contract
- Add dependency of 'serialization' module on 'resolution' so that it
could see contracts model.
Note that here we do a lot of seemingly unnecessary hoops, which in fact
necessary to respect existing module system (in particular, to be able
to extract ContractDescription declarations from 'descriptors' module to
make them invisible from reflection)
==========
Effect System introduction: 8/18
Rename addDeclarations -> registerModuleComponents
Use it to provide SamWithReceiverResolver extensions instead
Post construction on container composition can be achieved
but manually inserting injections where it seems appropriate
is bug prone
This fixes a bug where SamWithReceiverPlugin extension was not registered
for some containers in IDE which led to incorrect highlighting in IDE
Add IDE test for applying SamWithReceiver plugin
#KT-18062 Fixed
No package annotations are going to be loaded, and
TypeQualifierDefault/TypeQualifierNickname are no longer recognized by
default. Use the CLI argument "-Xload-jsr305-annotations" to enable this
behavior back
#KT-10942
Mikhael Bogdanov