Currently if there is an error in a function call, FIR would report the
entire expression if this call is qualified, but *only* the name if it's
not qualified. For example, assume the following two calls are all
contains some errors.
```
a.foo(1,2,3)
^^^^^^^^^^^^
bar(1,2,3)
^^^
```
The entire call of `foo` is reported since it's qualified. But only the
reference `bar` is reported since it's not qualified. This limits the
usage of position strategies because the IDE does not allow position
strategies to go outside of the initially reported PSI element
(org.jetbrains.kotlin.idea.fir.highlighter.KotlinHighLevelDiagnosticHighlightingPass#addDiagnostic).
This change passes both the original error named reference and the
surrounding qualified access expression and defer the decision of which
to use to the reporting logic.
For unresolved reference and checks on `super` keyword, the position
strategy should not highlight the surrounding parentheses. Hence a new
position strategy `REFERENCED_NAME_BY_QUALIFIED` is added.
In addition, this change also has the following side effect
* some diagnostics are no longer reported when there is a syntax error
since the higher level structure does not exist when there is a syntax
error
Similarly to FIR diagnostic tests. This commit enable all available test
data and check the reported error messages by FIR. This helps identify
some issues in formatting of FIR diagnostics.
The changes on the test file are mechanically generated. Failed tests
are disabled with `// IGNORE_FIR` and are re-enabled in the second
commit.
It seems unnecessary to force all quickfixes to fit the `HLQuickfix`
API, especially for those existing trivial fixes that simply modifies
PSI tree. This change further loosen the API of `HLDiagnosticFixFactory`
to allow it to create arbitrary `IntentionAction` objects. This also
avoids code duplication (for example, specify the family name again in
`ReplaceCallFixFactories`).
`HLQuickfix` and the input/target paradighm can still be used where
applicable.
The factory does not need to care about what target PSI and input a
quick fix should need. We only need to ensure these two types match when
an `HLQuickfix` is created. With this constraint loosened, now one
factory can register multiple quickfixes applied on different targets
and different input. This makes it much more flexible when implementing
quickfixes.
Creation of KotlinTargetsIndex takes too long,
even if Java project doesn't have any Kotlin files.
Remove function hasJsStdLib, as it takes too much time
because of recursively checking all dependencies (migrate to facets)
Also fix tests: Add Kotlin JS facet, where its needed
#KT-34351 Fixed
Finding type alias doesn't work if it's not top level because the class
ID doesn't match. There doesn't seem to be a easy way to make it work
so this commit simply makes the IDE tolerate it.
This is causing issues such as https://issuetracker.google.com/183423660.
Annotation processor options that are provided by the Android Gradle plugin
may contain references to files and file collections that are safe to
evaluate only at execution time. This change avoids eagerly creating
compiler plugin options for these options, as they are already a task input.
Test: AbstractKotlinAndroidGradleTests.testAgpNestedArgsNotEvaluatedDuringConfiguration
^KT-39715 In Progress
This will prioritize classifiers from the following sources
in the provided order
1) Classifiers from the target's modulesProvider
2) Classifiers from the traget's direct dependencies
3) Classifiers from the more common dependencies
In a Gradle process, the user.dir property is set to the directory
where the build was started. By default, if we start a child process
via project.javaexec, Gradle sets its working directory to the
directory of the current project. But passing Gradle's value of user.dir
to that process overrides this setting.
This makes tools started in a such way sensitive to directory the build
is started from.
This patch fixes this issue for K/N-related tools started
out-of-process by the MPP Gradle plugin. But this issue is still
relevant to in-process tool execution.
In a Gradle process, the user.dir property is set to the directory
where the build was started. By default, if we start a child process
via project.javaexec, Gradle sets its working directory to the
directory of the current project. But passing Gradle's value of user.dir
to that process overrides this setting.
This makes tools started in a such way sensitive to directory the build
is started from. Thus a test using relative paths may fail if it is
started from a wrong directory.
This patch fixes this issue for Kotlin/Native tests.
Tianyu Geng