e5ae32c removed bitcode embedding from tests. In particular, that commit
disabled bitcode embedding when compiling Swift code (e.g. in ObjCExport
tests).
It seems that bitcode embedding also enables adhoc codesigning in the
linker.
The linker doesn't seem to do adhoc codesigning by default for tvOS
arm64 simulator target, and without a signature the binaries can't run
on the simulator.
So disabling bitcode embedding also disabled adhoc codesigning and made
the tests fail on that target.
Fix this by explicitly passing `-Xlinker -adhoc_codesign` when compiling
Swift code in tests.
This commit is Low Level FIR part of changes around propagated
annotations (aka foreign annotations).
It includes such changes as:
* implicit type phase postpones foreign annotations resolution
* annotation arguments are requests resolution for postponed
annotations from implicit type phase as a pre-resolve step
* body resolve phase just calls lazy resolution for foreign annotations
on demand
* isResolved check for type annotations to be sure that all annotations
are resolved after annotation arguments phase
^KT-63042 Fixed
^KT-63681 Fixed
We shouldn't transform annotations not from declaration side due to
a possible different context and to avoid unexpected transformation of
unrelated declarations
Example:
```kotlin
fun implicitType1() = TopLevelObject.expectedType()
object TopLevelObject {
private const val privateConstVal = "privateConstVal"
fun expectedType(): @Anno(privateConstVal) Int = 4
}
```
Here we will try to transform the annotation from `expectedType`
during `implicitType1` and as the result, we will see unresolved
reference on the declaration side. This commit fixes this issue.
This solution is based on the fact that the compiler anyway will
resolve the propagated annotation on the declaration side.
And it doesn't matter if it is resolved before or after the call site
declaration transformation, because as a global result, we will observe
that all declarations are resolved correctly in the right context.
Hence, this commit fixes the issue in the case of "full resolution"
which is true for the compiler, but it is not correct for Low Level
FIR where we resolve declarations on demand. It will be solved in
the next commits
^KT-63042
Such annotations will be transformed as usual in `FirDeclarationsResolveTransformer.transformRegularClass`.
Also, this transformation doesn't have a corresponding class as a container
^KT-63042
Now annotations have the container symbol itself, so this property
is no longer needed.
This migration fixes issues with a missed container symbol, so now
all cases of lazy resolution from KtType are supported
^KT-63042
We should share the original instance to be able to later resolve it in
the original context. This commit returns the KT-60387 problem, but the
root cause (concurrent modification) will be fixed in the context of
KT-63042
^KT-63042
We cannot use only non-local declarations as anchors due to the same
resolution logic between member declarations of local classes, so we
have to support such cases as well
^KT-63042
This symbol will be used during resolution to avoid transformation
of annotations in the wrong context in the case of FIR node sharing.
The symbol should be some containing declaration symbol to be able
to answer the question "Are we own this annotation?" during resolution
^KT-63042
PreHmppDependenciesDeprecationIT test checks that all configurations are
resolved without any error. However, *DependencySources configurations
by nature can't be resolved all the time. As not all dependencies have
sources variants published.
It should exclude certain kotlin source set configurations, that
can't be resolved all the time for various reasons.
Particularly `dependencySources` since not all dependencies has
published source variants.
Move logic that creates configuration to resolve Dependency Sources
to SourceSet factory from IDE resolver. Because when it is created
during IDE import it will be reported as a warning. Since all
configurations and tasks must be created before IDE import starts.
^KT-63226 Verification Pending
Earlier versions of gradle doesn't return capabilities in resolved
artifact view. Therefore, it is not possible to match artifact by
cooridnates + capabilities.
^KT-63226
Yahor Berdnikau