As of Xcode 13.1 Swift 5.5 passes wrong libclang_rt to simulator targets
(similar to ours KT-47333). To workaround this problem, we explicitly
provide the correct one.
Inline functions called by the fragment is detected by the fragment
frontend and the PSI for them is supplied to the compiler backend.
For the purpose of compilation, the inline function is considered as
part of the same source module as the fragment, and then discarded
upon loading the compiled fragment for evaluation.
This commit changes the slice implementation used for
`USED_AS_EXPRESSION`.
Here is the problem as identified and mitigated by this commit:
Slices are key-value maps. They are not total over the domain of keys,
so "looking up" a key not in the slice is a valid operation, yielding
`null`.
A binding context is a collection of slices.
Binding contexts can be stacked as composite binding contexts to
e.g. facilitate scoped analyses. Looking up a key proceeds down the
stack, yielding the first non-null value, or `null` if no slice in the
stack of binding contexts contain that key.
A slice made by `createSimpleSetSlice` models a "set" of keys that can
be enlarged by inclusion: adding `(k, true)` to the slice indicates
`k` belongs to the set. `(k, false)` indicates non-membership.
However, looking up a key _not in_ the slice yields _false_, rather
than null.
Hence, simple set slices do not compose in composite binding traces.
This was encountered porting the expression evaluator to the IR
backend. PSI2IR uses `USED_AS_EXPRESSION` to generate expression body
functions properly. The frontend analysis of the fragment is layered
ontop of the binding context from the editor's analysis of the
underlying project being debugged, which contains speficially the
analysis results of inline functions called from the fragment.
FE1.0 always return kotlin.Unit as return type for constructors while
FIR returns the constructed class type. I am not sure which is more
desirable. Also, I am not sure how to make FE1.0 behave the same way.
If we implement default function with default parameters in inline
class, the receivers will be added to parameter list
(see ac7538a269). But since they
are not present in source parameters, we should not count them when we
compute mask for default parameters.
#KT-49977 Fixed
for performance reasons: (1) the snapshots are too big, and (2) they are
usually updated only at the end of the task execution--in a failed task
run, they are usually unchanged and therefore don't need to be restored.
The previous commit added gson to `incremental-compilation-impl` module.
However, gson is currently not added to -libraryjars for Proguard, so
running with -Pteamcity=true would fail with
```
> Task :kotlin-compiler:proguard
Warning: ... can't find referenced class com.google.gson.Gson
Warning: ... can't find referenced class com.google.gson.GsonBuilder
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
```
This commits adds -dontwarn com.google.gson.** to work around this
error. The proper fix is probably to add gson (and many other libraries)
to Proguard's -libraryjars.
Also visit a class file with ASM once to extract all information we need
in advance, instead of visiting the class file each time some piece of
info is needed.
as we need access to the lookup tracker to compute classpath changes
more efficiently and reduce the size of the saved classpath snapshot.
The previous commit only changed the files' paths, this
commit actually updates the files' contents.
Note that classpath snapshotting still happens in Gradle artifact
transforms. (However, the previous commit also moved the code for
classpath snapshotting together with the code for classpath diffing as
they are closely related.)
In reality plugin key was used only in two ways:
- found corresponding generator for member scope of generated class
- pass it to declaration origin so it can be read in backend IR plugin
Because of first usage plugin key was required to be an object, which
reduces functionality of second usage, because there was no way to
pass any additional info via key to IR (in future this usecase will be
covered with IR declaration attributes, but right now we don't have
them)
So now generator which created some class is now saved in its attributes
and plugins can use any keys they want. And since there is no other
usages of `FirExtension.key` it removed from FirExtension API at all
After that commit it's allowed to register any FIR plugin using
existing extension infrastructure (`-Xplugin` CLI argument,
plugin.xml for IDE plugins, etc)
Sergey Bogolepov