Add an option to link external gradle project
remove an option to load configuration manually because it cannot be implemented properly: script configurations for those scripts shouldn't be loaded during import for Gradle 6.0
^KT-37178 Fixed
For each externalGradleProject separate GradleScriptingSupport is created.
This allows to save script configurations by gradle projects
^KT-37806 Obsolete
^KT-35151 Fixed
The main goal is to extract logic that is related to Gradle scripts only to separate place.
Configurations for gradle scripts are updated during import simultaneously, there is no need to manage script configuration update for one file
Note that for Gradle less than 6.0 The DefaultScriptingSupport is used
For 193: it will be a simple notification at the bottom of the IDEA window
For 201: a floating notification in the editor is implemented near "Load Gradle Changes" icon
^KT-34443 Fixed
This fixes the problem in JVM IR backend which didn't pass bound
receiver value of an adapted function reference to the superclass
(kotlin/jvm/internal/AdaptedFunctionReference), which caused equals to
work incorrectly on such references (see changes in box tests).
Previously, bound adapted function reference was represented as
IrFunctionExpression to an adapter function which calls the callee. The
value of the bound receiver in that case could only be found in the body
of that adapter function. This is not very convenient, so this change
makes psi2ir produce a block of the adapter function + reference to it.
The bound receiver value is then found in the reference. This is
basically similar to what ProvisionalFunctionExpressionLowering is doing
for all function expressions. And since this IR structure is already
supported in FunctionReferenceLowering, the problem in the JVM IR is
fixed without any additional modifications.
However, inliners do not support this IR structure yet, see KT-38535 and
KT-38536.
Build systems like bazel rely on the output of a compilation being
deterministic. File checksums determine when an artifact is safe to
cache across builds. One can produce a klib deterministically by using a
fixed timestamp during klib compression.
Before this change:
```
$ kotlinc-native -produce library -output /tmp/first/color.klib Color.kt
$ kotlinc-native -produce library -output /tmp/second/color.klib Color.kt
$ shasum /tmp/first/color.klib /tmp/second/color.klib
bc3f73678ff025cfbec9009f9a851a8ca74e1037 /tmp/first/color.klib
65aa37886fbd53285f2e449a4dab6a2ad02732e6 /tmp/second/color.klib
```
After this change:
```
$ kotlinc-native -produce library -output /tmp/first/color.klib Color.kt
$ kotlinc-native -produce library -output /tmp/second/color.klib Color.kt
$ shasum /tmp/first/color.klib /tmp/second/color.klib
fcba304493916ae34d372188991f87b60a113cf3 /tmp/first/color.klib
fcba304493916ae34d372188991f87b60a113cf3 /tmp/second/color.klib
```
Vladimir Dolzhenko