Bumps minimist from 1.2.5 to 1.2.6.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps junit from 4.12 to 4.13.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Canonicalize paths before sending them to the pluggable FileWatchers and restore paths to their original potentially non-canonical form when they are returned from the file watchers.

This fixes an issue where the fs notifier binary behaved incorrectly when it was presented with symlinks. The fs notifier has some logic to avoid watching certain mount points, but if a user symlinks into a mount, the fs notifier's logic will be bypassed and the mount points will be watched.

This change is done in the FileWatcher rather than the native fs notifier because:

• The filewatcher supports pluggable filewatchers now, so it makes sense to give all of the pluggable file watchers canonical paths rather than making them all canonicalize the paths.
• The implementation in C for the native fs notifier would be similar to what is needed in Java for the FileWatcher and the java implementation is likely cleaner.

Change-Id: I61fd3ac4e3bfbb8b06c2d92190e6db36e7ff00c1

Intellij junit plugin allows filtering tests by the method name. In case of parameterized tests, the name includes parameters as well (e.g. test[parameter]). By default, attempt to run a test with a parameter in the name would fail since a method like that cannot be found. We already special case junit.Parameterized to work around the problem.

Extend logic handling parameterized runners to support TestParameterInjector. Do not fail on tests with arguments (allowed by TestParameterInjector).

Please note that similar problem exists for other parameterization libraries. There are workarounds in some libraries (e.g. Burst), however one cannot properly filter on parameter values without change on the IDE side.

For reference: TestParameterInjector issue.

Added a configuration option to use a VCS commit template if its available. This fixes https://youtrack.jetbrains.com/issue/IDEA-66355 for Git

Testing: Local Git repo shows the commit template

Bumps py from 1.5.4 to 1.10.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Resolves the issue with the installer always requiring a config file when installing in silent mode (https://github.com/microsoft/winget-pkgs/pull/179#issuecomment-630247055)

The sourceSet cache initializer can be called from several threads, but Gradle's project model is not thread safe, so we need to make sure only one thread at a time can initialize this.

This makes parallel model fetch work in the project I'm currently working on.

FYI @vladsoroka @nskvortsov

Hi @BasLeijdekkers,

This PR moves all the Java downgrading inspections into a unique path. Those inspections are used very differently from the others so it would be better to identify them easily. This way, they will be gathered like this (changes into bold):

• Java
• • Java language level downgrading issues
• • • Annotation
• • • Annotation class
• • • 'assert' statement
• • • Auto-boxing
• • • Auto-unboxing
• • • Diamond can be replaced with explicit type arguments
• • • Enhanced 'for' statement
• • • Enhanced 'switch'
• • • Enumerated class
• • • Multi-catch can be split into separate catch blocks
• • • Lambda can be replaced with anonymous class
• • • Stream API call chain can be replaced with loop
• • • 'Optional' can be replaced with sequence of 'if' statements
• • • Text block can be replaced with regular string literal
• • • Underscores in numeric literal
• • • Varargs method
• • • Variable type can be explicit

I have successfully tested it by injecting the code into my IntelliJ 2021.2.1 installation.

Some notes:

• Not sure why old controller is synchronized everywhere as most methods cannot possibly be invoked off the EDT. I made the 'MasterController' class thread safe in case loadHistory is invoked off the EDT. This never happens inside the idea-community codebase but maybe some other IntelliJ based IDEs do it.
• Not quite sure what the multiline flag is supposed to do. It's not ever set inside this codebase but maybe other IDEs use it. For this reason tried to modify as little of existing code as possible and preserve existing behavior.
• Added PCollections dependency to be able to efficiently snapshot state. It's a 24KB jar, so hopefully not a big deal
• The behavior is based on QtConsole, so where it behaves the same it's probably intentional, where not is probably a bug.
• It may make sense to move some classes from lang-impl to lang-api.

Massive changes to support Maven Polyglot. I was flying blind with this. I hope I've done OK. Currently, only Groovy is supported but it will be easy to add others. Changes:

• maven32-server-impl is removed
• maven33-server-impl added
• Polyglot type added to Maven settings panel
• Everywhere "pom.xml" is referenced, polyglot methods are used instead
• maven-polyglot-converter module added which converts on disk format to standard XML for internal use

This allows third parties to contribute ways to retrieve sources for possibly non-standard JAR files. Building block for https://github.com/JetBrains/intellij-community/pull/2127

A question: can we delegate to SourceSearchers the extraction of groupId, artifactId, and version? This is currently done in InternetAttachSourceProvider, but the logic used is not always correct.

Usage example might be P2SourceSearcher, which finds source JARs in p2 repositories.

Issues that are covered by this pr:

• https://youtrack.jetbrains.com/issue/KTIJ-23964/Debugger-smart-stepping-inside-inline-lambdas-declared-in-a-local-function-doesnt-work-for-IR-backend
• https://youtrack.jetbrains.com/issue/KTIJ-23965/Debugger-smart-stepping-into-inline-lambdas-doesnt-work-when-lambdas-are-declared-in-functions-with-the-same-name
• https://youtrack.jetbrains.com/issue/KTIJ-24090/Debugger-inline-lambda-breakpoints-sometimes-doesnt-work
• https://youtrack.jetbrains.com/issue/KTIJ-24091/Debugger-smart-stepping-steps-into-a-wrong-inline-lambda-on-the-same-line

Previously KotlinPositionManager relied on ClassNameCalculator to detect which function literal on a particular line matches the current jdi location. This lead to issues when ClassNameCalculator failed to compute class names correctly. For example, ClassNameCalculator computes class names of local functions according to the old backend naming scheme, which doesn't work for the IR backend. However, fixing ClassNameCalculator will not solve the issue, since there is no way to understand at runtime which backend was used for the compilation. Also, if the compiler naming scheme changes in the future, ClassNameCalculator will have to be updated again and again. This pr introduces a new heuristic to detect which inlined function literal corresponds to the given jdi location. The algorithm is based on inline marker variables borders, and while it doesn't solve the ClassNameCalculator issue completely, it still improves smart stepping and lambda breakpoints in a couple of cases.

Roughly speaking, the algorithm is based on the following logic:

Consider the example:

1.let { it }.let { it + 1 }.let { it + 2 } // Line X

Given a jdi location, we need to understand which inline lambda is the best fit for it. After checking variables that are visible on the location, we will see these marker variables start on line X:

$i$a-let-...$...$1  // 1 -- { it }
$i$a-let-...$...$2  // 2 -- { it + 1 }
$i$a-let-...$...$3  // 3 -- { it + 2 }

Each of these variables has visibility borders, and, for example, if the borders of variable 2 contain the given location, it means that we are in the { it + 1 } lambda.

This approach relies on inline variables borders instead of relying on ClassNameCalculator entirely. However, it still needs ClassNameCalculator to detect which inlined lambdas are 'visible' in the current context. For example:

inline fun foo(f: () -> Unit) = f()
fun bar(f: () -> Unit) = f()

fun main() {
    foo { bar { foo { println() } } } // Line X
}

In this case we have two inline lambdas on line X, however only one marker variable will be visible in context of main() and bar.invoke() functions. To handle cases like this, the algorithm relies on ClassNameCalculator to detect if we are inside a non-inline lambda or not.

@madsager

Hi @amaembo,

This PR introduces the OrderedBinaryExpression class. I have already written this when I contributed to Eclipse IDE. It reads a PSI binary expression and then you can read it in the order you want, no matter what was the original order. It is very useful. Tell me if there is a better package than com.intellij.psi.util.

This PR changes the Redundant String operation and String.equals() can be replaced by String.isEmpty() inspections. Tell me if you agree the new labels.

What steps will reproduce the issue?

1. Go to File → Settings... → Editor → Inspections
2. Enable Redundant String operation
3. Enable Severity: Warning
4. Add this method in a Java 11 class:

  boolean isBlank(String text) {
    return "".equals(text.strip());
  }

What is the expected result? The inspection Redundant String operation is suggested. What happens instead? The inspection Redundant String operation is not suggested.

RedundantStringOperationInspection should write:

text.isBlank()

...for the following inputs:

"".equals(text.strip())
text.strip().equals("")
text.strip().length() == 0
0 == text.strip().length()
text.strip().length() < 1

It should also handle negative forms.

I have added and successfully run unit tests.

This option is really annoying, I sometimes have lines that exceed that value (e.g. minified files). I never ever want them to be hard wrapped, this option allows this. If you do not need it, simply set the maximum hard wrap not that high, leave it at the default value (120)

Previously,

for (i in (0..<10)) {
    println i
}

was transformed into

0..<10.each { i ->
    println i
}

However, this calls the each method on 10 instead of the range. To fix the transformation, the range needs parentheses. It seems like returning the range precedence fixes the issue.

I didn't find any existing test for the intention, so I created a new file, similar to the EachToForIntentionTest one.