48a684c0 added custom LLVM diagnostic handler, using JvmCallbacks machinery,
thus triggered a bug in the latter: callbacks are cached and outlive the compilation session,
but rely on memory that is reclaimed at the end of the compilation session.
So during a subsequent compilation in the same process (e.g. when the compiler runs in the
Gradle daemon process), LLVM might call the callback which accesses the reclaimed memory,
which in turn causes the crash.
Fix this by forcing JvmCallbacks to allocate memory that doesn't "expire" at the end of the compilation session.
There is some behavior change regarding the new WrapWithSafeLetCall quickfix
1. it now works correctly on binary expressions by wrapping it with `()`
2. it now looks for a nullable position upward and do the modification there,
if possible. For example, consider the following code
```
fun bar(s: String): String = s
fun test(s: String?) {
bar(bar(bar(<caret>s)))
}
```
After applying this fix, FE1.0 yields
```
bar(bar(s?.let { bar(it) }))
```
while the new implementation yields
```
s?.let { bar(bar(bar(it))) }
```
This behavior aligns with FE1.0 if `bar` accepts nullable values.
(e.g., `nullable.a = b`), and use positioning strategies to locate the
dot in the LHS expression.
Without it, only the callee reference is reported on, which makes the
highlighting of the error and application of quickfixes incorrect in the
IDE.
Also fixed issue with annotated and/or labeled expressions on LHS of
assignment (e.g., `(@Ann label@ i) = 34`).
`iterator()` function that does NOT have `operator` modifier.
This is different from FE1.0. Adding `!!` will then surface the error
that `operator` modifier needs to be added (with corresponding fix).
UNSAFE_OPERATOR_CALL, UNSAFE_INFIX_CALL, ITERATOR_ON_NULLABLE,
ARGUMENT_TYPE_MISMATCH, RETURN_TYPE_MISMATCH.
TODO: Don't offer fix when target is known to be null (from data flow
analysis).
isAvailable and in invoke) by moving computation of element to modify
to before instantiation (i.e., to the factories or equivalent).
This lets us to move it to idea-frontend-independent and re-use it FIR.
This commit fixes:
```
org.gradle.internal.metaobject.AbstractDynamicObject$CustomMessageMissingMethodException:
Could not find method intellijDep() for arguments [] on object of type
org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler
```
Dmitriy Novozhilov