Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add comptibility for 2024.1 IDEs #3569

Merged
merged 15 commits into from
Jul 15, 2024

Conversation

ashleysommer
Copy link
Contributor

@ashleysommer ashleysommer commented Apr 7, 2024

Alternative to #3567

There were a couple more changes required other than simply bumping the IntelliJ IDE version number.

When I try to build this plugin against 2024.1 IDEs and run the Test suite, I get the error NoSuchFieldError: FILE_HASHING_STRATEGY. See relevant underlying IDE code change

While in the process of fixing that issue, I upgraded the org.jetbrains.intellij gradle plugin to v1.17.3 as recommended in the IntelliJ docs. Unfortunately that brings in some other gradle dependencies that require gradle v7.6.4 minimum see here for details.

So this PR bumps IDE version to "2024.1", adds that version to the test suite PluginVerifier matrix, fixes the NoSuchFieldError in jps-build tests, bumps org.jetbrains.intellij gradle plugin to v1.17.3, and bumps gradlewrapper version to v7.6.4.

./gradlew wrapper --gradle-version=7.6.4
To fix gradle issue: gradle/gradle#27156
…, it was removed in 2024.1. (Note, this is only used in the jps-build test suite).

This also removes references to Trove THashSet, and no longer stores File directly in sets or collections.
See JetBrains/intellij-community@560e8fc
@ashleysommer ashleysommer mentioned this pull request Apr 8, 2024
@gaggle
Copy link

gaggle commented Apr 8, 2024

Thanks for doing this.

Would it be helpful if we try out the plugin? If you attach the plugin I'd be happy to install it and give it a go, so we can help boost the confidence that the plugin works as advertised?

@ashleysommer
Copy link
Contributor Author

@gaggle Yes, I had the same thought. I'll finish my current round of testing, and later today I'll attach the .zip for users to try.

@ashleysommer
Copy link
Contributor Author

ashleysommer commented Apr 8, 2024

Here is the build I'm currently personally using.
Note, it also includes changes from #3562 to fix launching IEx run configurations on Elixir 1.15+, and includes #3563 to fix debugging on Erlang/OTP 26.

intellij-elixir-17.0.0-pre+20240408035552.zip

Copy link

@junioroo junioroo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@allenwyma
Copy link

hi @ashleysommer having an issue with the plugin where some coloring seems off and when i tried adding a moduledoc, the """ didn't get autocompleted.

@ashleysommer
Copy link
Contributor Author

hi @ashleysommer having an issue with the plugin where some coloring seems off and when i tried adding a moduledoc, the """ didn't get autocompleted.

Yeah, there's probably a bunch of things still not working correctly.

I'm actually very new to Elixir, I'm still learning what the features are and I was only using this plugin for 1 week before Jetbrains 2024.1 IDEs were released, and I'm still learning what this plugin is even capable of or what it should do correctly.

@gaggle
Copy link

gaggle commented Apr 9, 2024

It LGTM too!

Copy link

@jameskbride jameskbride left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, thanks for tacking this, I can't wait to get my hands on it! See my comments. We also need to update the CHANGELOG.md file as well. Thanks!

@@ -82,7 +82,7 @@ allprojects {
}

runPluginVerifier {
ideVersions = ["2023.3"]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on previous compatibility PRs we normally drop support for the previous version, so this should probably just be ["2024.1"]

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old version is only dropped if a required code change makes it impossible to build for both versions. It's a coincidence that that has been the case for recent one.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, thanks for the clarification!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The commit I used for reference was this one: 876b770
That does simply add the new version to the list, as I've done here.

@@ -70,7 +70,7 @@ allprojects {
pluginDescription.set(bodyInnerHTML("resources/META-INF/description.html"))

sinceBuild = "233.11799.241"
untilBuild = "233.*"
untilBuild = "241.*"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on previous compatibility PRs sinceBuild typically matches untilBuild since we're dropping support for previous versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't seen any compatibility PRs in this repo where the sinceBuild matches the untilBuild, that doesn't seem right.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following warning shows for this:

> Task :verifyPluginConfiguration
[gradle-intellij-plugin :verifyPluginConfiguration] The following plugin configuration issues were found:
- The 'since-build' property is lower than the target IntelliJ Platform major version: 233.11799.241 < 241.

I believe it needs to match.

Since we also only support the last version of the IDE per version, I think this is fine?

@@ -8,7 +8,7 @@ jobs:

strategy:
matrix:
ideaVersion: [ "2023.3" ]
ideaVersion: [ "2023.3", "2024.1" ]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure this can just be ["2024.1"] since we normally just support the current version.


@Override
public void logDeletedFiles(Collection<String> paths) {
for (String path:paths){
myDeletedFiles.add(new File(path));
myDeletedFiles.add(new File(path).getAbsolutePath());

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a change in behavior? I'm not sure if path was previously absolute or relative (it looks relative).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change is the set is storing the string version of the file instead of the File object. In the previous version, the handler was calling .getAbsolutePath() on every File object in the set, so we simply do that here instead and save a step.

Comment on lines +654 to +664
private fun usages(): String {
val ideVersion = Version.parseVersion(ApplicationInfoEx.getInstance().fullVersion)
val usagesString = if (ideVersion === null || ideVersion.lessThan(2021,2,0)) {
"Found usages"
} else {
} else if (ideVersion.lessThan(2024,1,0)) {
"Usages in"
} else {
"Usages"
}
return usagesString
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand what's driving this change. Can you walk me through it please?

Copy link
Contributor Author

@ashleysommer ashleysommer Apr 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to help some tests pass.

In February, IntelliJ changed the wording of the text representation of the find usages response. That change made its way into all 2024.1 IDEs and broke these tests.
JetBrains/intellij-community@0706bea

Note, there are still some other changes in 2024.1 that are preventing these tests from actually passing, but this is the simple first step to remedy the bulk of the error messages.

Copy link

@noizu noizu Apr 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to support previous build versions if we are bocking these versions with the from-version attribute?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, we really don't need the case to handle the pre-2021.2 usages string.
It had been in the plugin code right up to and including the 2023.3 release, thats why I left it in there in this change, but refactoring it like this could be a good opportunity to remove that old version compatibility.

@colmben
Copy link

colmben commented Apr 22, 2024

Thanks for looking at this! Note that while it does allow the plugin to load I am seeing various UI issues with intellij-elixir-17.0.0-pre+20240408035552.zip. Most annoyingly I have lost the matching brackets highlight - you don't realise how much you use that until it is gone! Also comments are showing as black, the same as normal code, which is getting very confusing.

Screenshot 2024-04-22 at 11 38 14

Is anyone seeing either of those issues?

Edit - also we seem to have lost the ability to run tests via the IDE

@noizu
Copy link

noizu commented Apr 25, 2024

This worked fine for me with just updating until-version. I also played with changing org.jetbrains. I did need to purge m2 deps however. #3579

@jameskbride
Copy link

@ashleysommer @KronicDeth I have a commit in my fork that I believe fixes the failing FindUsagesTest tests.

I could use some feedback on this; I think the difference is just formatting for the usage output, in which case this commit should be good.

I'm also still seeing the following test failures:

Configuration file for j.u.l.LogManager does not exist: /Users/jameskbride/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/2024.1/181fa36f74690e64a81a8e06ceda9480d2a6c626/ideaIC-2024.1/test-log.properties

ERLANG_SDK_HOME is not set
junit.framework.AssertionFailedError: ERLANG_SDK_HOME is not set
	at junit.framework.Assert.fail(Assert.java:57)
	at junit.framework.Assert.assertTrue(Assert.java:22)
	at junit.framework.Assert.assertNotNull(Assert.java:256)
	at junit.framework.TestCase.assertNotNull(TestCase.java:399)
	at org.elixir_lang.jps.BuilderTest.erlangSdkHome(BuilderTest.java:49)
	at org.elixir_lang.jps.BuilderTest.addErlangSdk(BuilderTest.java:139)
	at org.elixir_lang.jps.BuilderTest.setUp(BuilderTest.java:172)
	at com.intellij.testFramework.UsefulTestCase.invokeSetUp(UsefulTestCase.java:430)
	at com.intellij.testFramework.UsefulTestCase.defaultRunBare(UsefulTestCase.java:422)
	at com.intellij.testFramework.UsefulTestCase.lambda$runBare$12(UsefulTestCase.java:491)
	at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$3(EdtTestUtil.java:80)
	at com.intellij.openapi.application.impl.RwLockHolder.runWriteIntentReadAction(RwLockHolder.kt:70)
	at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$4(EdtTestUtil.java:79)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.kt:326)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)


ERLANG_SDK_HOME is not set
junit.framework.AssertionFailedError: ERLANG_SDK_HOME is not set
	at junit.framework.Assert.fail(Assert.java:57)
	at junit.framework.Assert.assertTrue(Assert.java:22)
	at junit.framework.Assert.assertNotNull(Assert.java:256)
	at junit.framework.TestCase.assertNotNull(TestCase.java:399)
	at org.elixir_lang.jps.BuilderTest.erlangSdkHome(BuilderTest.java:49)
	at org.elixir_lang.jps.BuilderTest.addErlangSdk(BuilderTest.java:139)
	at org.elixir_lang.jps.BuilderTest.setUp(BuilderTest.java:172)
	at com.intellij.testFramework.UsefulTestCase.invokeSetUp(UsefulTestCase.java:430)
	at com.intellij.testFramework.UsefulTestCase.defaultRunBare(UsefulTestCase.java:422)
	at com.intellij.testFramework.UsefulTestCase.lambda$runBare$12(UsefulTestCase.java:491)
	at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$3(EdtTestUtil.java:80)
	at com.intellij.openapi.application.impl.RwLockHolder.runWriteIntentReadAction(RwLockHolder.kt:70)
	at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$4(EdtTestUtil.java:79)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.kt:326)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

These pass for me locally on the main branch and fail on @ashleysommer's branch, so I don't believe it is simply my environment setup.

@ashleysommer
Copy link
Contributor Author

@ashleysommer @KronicDeth I have a commit in my fork that I believe fixes the failing FindUsagesTest tests.

I could use some feedback on this; I think the difference is just formatting for the usage output, in which case this commit should be good.

Yes, that is the main remaining test failure that I've been working to fix the last couple of weeks.
Unfortunately simply changing the formatting to match the new version is not good enough because that breaks compatibility with pre-2024.1 IDEs. Its very hard to nail down in the IntelliJ IDE source code exactly where this behaviour changed and when. I actually think the whitespace formatting difference was an unintentional change by Jetbrains, introduced by fixing or changing something different or unrelated, and it may be fixed/reverted in the future if it was unintentional.

I've been working on a way that can assert success of the tests regardless of the whitespace formatting in the returned usages serialization.

I'm also still seeing the following test failures:
...
These pass for me locally on the main branch and fail on @ashleysommer's branch, so I don't believe it is simply my environment setup.

I don't see any of those ERLANG_SDK_HOME errors in my local tests in this branch.

@ashleysommer
Copy link
Contributor Author

@colmben

Most annoyingly I have lost the matching brackets highlight - you don't realise how much you use that until it is gone!

I think I've narrowed down where this issue is coming from. I've found one difference in the parser in 2024.1 regarding brackets that must be causing this.

@szymon-jez
Copy link

Unfortunately simply changing the formatting to match the new version is not good enough because that breaks compatibility with pre-2024.1 IDEs

Is this needed? From what I remember recent updates of this plugin required an upgrade of the IDE.

@ashleysommer
Copy link
Contributor Author

From what I remember recent updates of this plugin required an upgrade of the IDE.

I wouldn't know, I only started using this plugin in March 2024, after IntelliJ 2023.3 was released. Looking back through the upgrade commits, it seems like sometimes the min version is bumped, sometimes it isn't.

Is this needed?

Well, no its not strictly needed, but all other changes in this branch have kept backwards compatibility with 2023.3 IDE, normally when I contribute to an open source project the expectation is to avoid breaking changes at all costs wherever possible.

@szymon-jez
Copy link

Here is the build I'm currently personally using. Note, it also includes changes from #3562 to fix launching IEx run configurations on Elixir 1.15+, and includes #3563 to fix debugging on Erlang/OTP 26.

intellij-elixir-17.0.0-pre+20240408035552.zip

I have tested your build and it was not working with the newest IDEA, but it does work with the previous one making IEx and debugging work in the IDE with Elixir 1.16 and Erlang OTP 26. This is very helpful - thanks! Looking forward to seeing those in the next release.

@vkuprin
Copy link

vkuprin commented May 9, 2024

Here is the build I'm currently personally using. Note, it also includes changes from #3562 to fix launching IEx run configurations on Elixir 1.15+, and includes #3563 to fix debugging on Erlang/OTP 26.
intellij-elixir-17.0.0-pre+20240408035552.zip

I have tested your build and it was not working with the newest IDEA, but it does work with the previous one making IEx and debugging work in the IDE with Elixir 1.16 and Erlang OTP 26. This is very helpful - thanks! Looking forward to seeing those in the next release.

That binary you shared installs pretty well on my IntelliJ IDEA 2024.1.1 (Ultimate Edition) Build #IU-241.15989.150, built on April 29, 2024

@jmSfernandes
Copy link

Hey guys, is there any ETA for this?
I really love this plugin... but right now, this is the only thing blocking me from updating IntelliJ IDEA
Can anyone confirm that the zip file works??
I have seen mixed responses 🤔

@gaggle
Copy link

gaggle commented May 15, 2024

Hey guys, is there any ETA for this? I really love this plugin... but right now, this is the only thing blocking me from updating IntelliJ IDEA Can anyone confirm that the zip file works?? I have seen mixed responses 🤔

It certainly works fine for me, across both an Intel Mac and an ARM Mac. I have IntelliJ Ultimate 2024.1.1 installed, with
17.0.0-pre+20240408035552 of this plugin added via the zip of this thread.

@allenwyma
Copy link

Hey guys, is there any ETA for this? I really love this plugin... but right now, this is the only thing blocking me from updating IntelliJ IDEA Can anyone confirm that the zip file works?? I have seen mixed responses 🤔

well, it "works", but found that like the auto complete of say parentheses etc are gone and the colors come and go if the syntax is "broken" which happens as you type character by character.

@noizu
Copy link

noizu commented May 16, 2024

per formatting issues. branch by abstraction. Just clone the formatting logic, add a toggle to switch between the new/old logic. Make it work for just the new ide version then start comparing the change diffs to make the new iteration backwards compatible.

@noizu
Copy link

noizu commented May 16, 2024

If you can hack that to work properly I can help with the switching logic.

@billylaing
Copy link

I've been using Zed on MacOS for elixir. The inline Heex syntax highlighting has changed my life.

I have nothing but love for all the work @KronicDeth put into this plugin but I can understand why maintaining a plugin for a profitable company is not that rewarding. Especially with breaking changes from upstream.

@alexnogueirasilva
Copy link

I didn't want to go back to VSCode, nor leave Linux, but I see that the main tools come out first for Mac. Maybe I'll change my operating system since I'm diving into Elixir and don't want to spend time adjusting Neovim.

@billylaing
Copy link

I didn't want to go back to VSCode, nor leave Linux, but I see that the main tools come out first for Mac. Maybe I'll change my operating system since I'm diving into Elixir and don't want to spend time adjusting Neovim.

You could try building from source!

https://zed.dev/docs/development/linux

@joze144
Copy link

joze144 commented Jun 26, 2024

I've been using Zed on MacOS for elixir. The inline Heex syntax highlighting has changed my life.

I have nothing but love for all the work @KronicDeth put into this plugin but I can understand why maintaining a plugin for a profitable company is not that rewarding. Especially with breaking changes from upstream.

I too migrated to Zed for now. It's fast and just works. Can also keep pretty much the same key bindings. But I do miss a lot of features that Jetbrains IDEs offer

@Bishwas-py
Copy link

I've been using Zed on MacOS for elixir. The inline Heex syntax highlighting has changed my life.
I have nothing but love for all the work @KronicDeth put into this plugin but I can understand why maintaining a plugin for a profitable company is not that rewarding. Especially with breaking changes from upstream.

I too migrated to Zed for now. It's fast and just works. Can also keep pretty much the same key bindings. But I do miss a lot of features that Jetbrains IDEs offer

Thanks for suggestion boss. Will be trying zed...

@joshuataylor
Copy link
Collaborator

Also #3362 (comment) should hopefully give you more understanding and empathy about opensource development.

@joshuataylor
Copy link
Collaborator

Thank you so much for this contribution, I will take a look through the code, the existing reviews and will try and merge in the next few days, if everything goes well.

Please also see #3598 .

Copy link
Collaborator

@joshuataylor joshuataylor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work so far, thanks so much.

For reference the following tests need to be fixed - I'll get these done.

/tests/org/elixir_lang/FindUsagesTest.kt#L161

There are some slight differences in indentation between the expected and actual results. Here's a diff to highlight the changes:

 <root> (3)
  Usages (3)
   Call definition clause (2)
    light_idea_test_case (2)
      (2)
      function_recursive_usage.ex (2)
-      2def function([], acc), do: acc
-      4def function([h | t], acc) do
+      2  def function([], acc), do: acc
+      4  def function([h | t], acc) do
   Value read (1)
    light_idea_test_case (1)
      (1)
      function_recursive_usage.ex (1)
-      5function(t, [h | acc])
+      5    function(t, [h | acc])

The main differences are:

  1. Additional indentation (2 spaces) before def on lines 2 and 4
  2. Additional indentation (4 spaces) before function on line 5

23 failing tests, but if we fix the root cause, they should pass.

And:
/tests/org/elixir_lang/code_insight/highlighting/brace_matcher/Issue443.java#L17

it tests this file:

/testData/org/elixir_lang/code_insight/highlighting/brace_matcher/issue_443/do_block.ex#L1

error is:

`do` not matched to `end`

I believe 2024.1 changed how the Usages work.

In 2023.x:
```kotlin
val usages =
myFixture.testFindUsagesUsingAction("module_attribute_usage.ex",
"kernel.ex")
.map { it as UsageInfo2UsageAdapter }
```

In the debugger shows:
```
0 = {ReadWriteAccessUsageInfo2UsageAdapter@19239} "4|def usage, |do|:
|@|module_attribute"
1 = {ReadWriteAccessUsageInfo2UsageAdapter@19240} "2|@|module_attribute|
|1"
```

For 2024.1, this shows:
```
0 = {ReadWriteAccessUsageInfo2UsageAdapter@19421} "2|
|@module_attribute| 1"
1 = {ReadWriteAccessUsageInfo2UsageAdapter@19422} "4|  def usage, do:
|@module_attribute"
```

I believe it not shows the whitespace for the file, where previously it
didn't.
@joshuataylor
Copy link
Collaborator

Another update/devlog.. I should move this somewhere else, probably.

As noted in the Proposed Roadmap, after this task we'll try and figure out how to reduce friction and "modernise" the process - a lot has changed in the last few years with both the Java/Kotlin and the IDEA Plugin Platform ecosystem.

Right now we are down to a few errors when testing.

  1. org.elixir_lang.code_insight.highlighting.brace_matcher
    I have no idea why this is now failing. I have a feeling that because the amount of changes also required in the usages test, this might have changed.

This seems to return NonTrivial now. /src/org/elixir_lang/code_insight/highlighting/brace_matcher/NonTrivial.java#L11.

  1. getApplication() is null
Configuration file for j.u.l.LogManager does not exist: /home/josh/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/2024.1/181fa36f74690e64a81a8e06ceda9480d2a6c626/ideaIC-2024.1/test-log.properties

Cannot invoke "com.intellij.openapi.application.Application.getService(java.lang.Class)" because the return value of "com.intellij.openapi.application.ApplicationManager.getApplication()" is null
java.lang.NullPointerException: Cannot invoke "com.intellij.openapi.application.Application.getService(java.lang.Class)" because the return value of "com.intellij.openapi.application.ApplicationManager.getApplication()" is null
  at com.intellij.notification.NotificationGroupManager.getInstance(NotificationGroupManager.java:19)
  at org.elixir_lang.jps.HomePath.eachEbinPath(HomePath.java:47)
  at org.elixir_lang.jps.BuilderTest.addErlangSdk(BuilderTest.java:143)
  at org.elixir_lang.jps.BuilderTest.setUp(BuilderTest.java:172)
  at com.intellij.testFramework.UsefulTestCase.invokeSetUp(UsefulTestCase.java:430)
  at com.intellij.testFramework.UsefulTestCase.defaultRunBare(UsefulTestCase.java:422)
  at com.intellij.testFramework.UsefulTestCase.lambda$runBare$12(UsefulTestCase.java:491)
  at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$3(EdtTestUtil.java:80)
  at com.intellij.openapi.application.impl.RwLockHolder.runWriteIntentReadAction(RwLockHolder.kt:70)
  at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$4(EdtTestUtil.java:79)
  at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
  at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
  at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
  at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
  at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
  at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
  at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
  at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.kt:326)
  at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
  at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
  at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
  at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
  at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
  at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)


Cannot invoke "com.intellij.openapi.application.Application.getService(java.lang.Class)" because the return value of "com.intellij.openapi.application.ApplicationManager.getApplication()" is null
java.lang.NullPointerException: Cannot invoke "com.intellij.openapi.application.Application.getService(java.lang.Class)" because the return value of "com.intellij.openapi.application.ApplicationManager.getApplication()" is null
  at com.intellij.notification.NotificationGroupManager.getInstance(NotificationGroupManager.java:19)
  at org.elixir_lang.jps.HomePath.eachEbinPath(HomePath.java:47)
  at org.elixir_lang.jps.BuilderTest.addErlangSdk(BuilderTest.java:143)
  at org.elixir_lang.jps.BuilderTest.setUp(BuilderTest.java:172)
  at com.intellij.testFramework.UsefulTestCase.invokeSetUp(UsefulTestCase.java:430)
  at com.intellij.testFramework.UsefulTestCase.defaultRunBare(UsefulTestCase.java:422)
  at com.intellij.testFramework.UsefulTestCase.lambda$runBare$12(UsefulTestCase.java:491)
  at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$3(EdtTestUtil.java:80)
  at com.intellij.openapi.application.impl.RwLockHolder.runWriteIntentReadAction(RwLockHolder.kt:70)
  at com.intellij.testFramework.EdtTestUtil.lambda$runInEdtAndWait$4(EdtTestUtil.java:79)
  at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
  at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
  at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
  at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
  at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
  at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
  at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
  at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.kt:326)
  at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
  at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
  at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
  at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
  at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
  at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Trawling through Google shows this issue arised about a year ago.

This post has "answered in Slack"... but Slack doesn't keep history and the post is closed 🙄.

  1. intellij-platform-gradle-plugin might have caused junit issues
    We're definitely going to upgrade to 2.0 in the next phase, as there are some great changes and makes the DX much, MUCH better when developing plugins.

So we'll need to dig into why this is happening.

@joshuataylor
Copy link
Collaborator

Okay, figured it out, we needed to change key to language in plugin.xml 🤦.

Thanks for your work to get this started, I've added a few changes and it's green now, so I'm going to push this.

@joshuataylor joshuataylor merged commit b49a4a4 into KronicDeth:main Jul 15, 2024
2 checks passed
@miguno
Copy link

miguno commented Jul 16, 2024

Thanks so much!

@reneleonhardt
Copy link

Awesome! Will there be a new release for IntelliJ 2024 users?
There is only one milestone which seems not be getting closed soon...
https://github.com/KronicDeth/intellij-elixir/milestones

@joshuataylor
Copy link
Collaborator

Yes, there will be once I'm confident things work as expected.

Right now I think there is an issue with upgrading and facets.

I'm thinking of adding a new button for clearing facets, incase things "bug out", which is acceptable as you just need to readd the Erlang/Elixir SDKs.

Please see #3604

The other problem IntelliJ now enforces a fast UI, which is great. But a lot of the code for the Elixir plugin needs to be ported. Until then, you can use ide.slow.operations.assertion=false as a setting. I thought there was a way to define it per-module, but I can't find the docs for it now..

You should be able to use this without much issues with that setting, we'll aim to get this sorted by moving it to background threads etc.

rNoz pushed a commit to rNoz/intellij-elixir that referenced this pull request Jul 27, 2024
* Update gradlewrapper to v7.6.4
./gradlew wrapper --gradle-version=7.6.4
To fix gradle issue: gradle/gradle#27156

* Remove use of `FileUtil.FILE_HASHING_STRATEGY` from Intellij FileUtil, it was removed in 2024.1. (Note, this is only used in the jps-build test suite).
This also removes references to Trove THashSet, and no longer stores File directly in sets or collections.
See JetBrains/intellij-community@560e8fc

* Add support for 2024.1 IDEs (and runs tests correctly against 2024.1)

* Update usages group wording for 2024.1

* Fix more sdk configuration commits in application RW thread, fixes compatibility with IDEs v2024.1

* Fix whitespace in tests due to 2024.1 change

I believe 2024.1 changed how the Usages work.

In 2023.x:
```kotlin
val usages =
myFixture.testFindUsagesUsingAction("module_attribute_usage.ex",
"kernel.ex")
.map { it as UsageInfo2UsageAdapter }
```

In the debugger shows:
```
0 = {ReadWriteAccessUsageInfo2UsageAdapter@19239} "4|def usage, |do|:
|@|module_attribute"
1 = {ReadWriteAccessUsageInfo2UsageAdapter@19240} "2|@|module_attribute|
|1"
```

For 2024.1, this shows:
```
0 = {ReadWriteAccessUsageInfo2UsageAdapter@19421} "2|
|@module_attribute| 1"
1 = {ReadWriteAccessUsageInfo2UsageAdapter@19422} "4|  def usage, do:
|@module_attribute"
```

I believe it not shows the whitespace for the file, where previously it
didn't.

* pin versions

* use BasePlatformTestCase to stop warning

* add do block match test

* set 241.0 as the version, to fix certain intellij warnings

* fix key

* revert tests

* use thread

---------

Co-authored-by: Josh Taylor <[email protected]>
joshuataylor added a commit that referenced this pull request Aug 3, 2024
… Comment) (#3582)

* feat: enabling proper code generation for comments (toggleable, Comment with Line/Block Comment)

* Add the correct ERL and elixir arguments for starting IEx depending on the version of elixir sdk

* Bundle latest OtpErlang.jar from JInterface v1.14 for OTP v26

* Infer OTP_RELEASE & ERLANG_SDK_HOME if no environment variable is set (#3600)

* Add compatibility for 2024.1 IDEs (#3569)

* Update gradlewrapper to v7.6.4
./gradlew wrapper --gradle-version=7.6.4
To fix gradle issue: gradle/gradle#27156

* Remove use of `FileUtil.FILE_HASHING_STRATEGY` from Intellij FileUtil, it was removed in 2024.1. (Note, this is only used in the jps-build test suite).
This also removes references to Trove THashSet, and no longer stores File directly in sets or collections.
See JetBrains/intellij-community@560e8fc

* Add support for 2024.1 IDEs (and runs tests correctly against 2024.1)

* Update usages group wording for 2024.1

* Fix more sdk configuration commits in application RW thread, fixes compatibility with IDEs v2024.1

* Fix whitespace in tests due to 2024.1 change

I believe 2024.1 changed how the Usages work.

In 2023.x:
```kotlin
val usages =
myFixture.testFindUsagesUsingAction("module_attribute_usage.ex",
"kernel.ex")
.map { it as UsageInfo2UsageAdapter }
```

In the debugger shows:
```
0 = {ReadWriteAccessUsageInfo2UsageAdapter@19239} "4|def usage, |do|:
|@|module_attribute"
1 = {ReadWriteAccessUsageInfo2UsageAdapter@19240} "2|@|module_attribute|
|1"
```

For 2024.1, this shows:
```
0 = {ReadWriteAccessUsageInfo2UsageAdapter@19421} "2|
|@module_attribute| 1"
1 = {ReadWriteAccessUsageInfo2UsageAdapter@19422} "4|  def usage, do:
|@module_attribute"
```

I believe it not shows the whitespace for the file, where previously it
didn't.

* pin versions

* use BasePlatformTestCase to stop warning

* add do block match test

* set 241.0 as the version, to fix certain intellij warnings

* fix key

* revert tests

* use thread

---------

Co-authored-by: Josh Taylor <[email protected]>

* Add 18.0.0 changelog, fix version (#3602)

* support only the newest version.

* remove tests for now, kind of pointless

---------

Co-authored-by: Ashley Sommer <[email protected]>
Co-authored-by: Josh Taylor <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2024.1 compatibility Needed to fix 2024.1
Projects
None yet
Development

Successfully merging this pull request may close these issues.