SwiftUI Demo App not working.

[Qubik65536]

I am trying to port STTextView-Plugin-Neon to iOS, but there's an issue I encountered when working with SwiftUI.

Note

I first encountered this issue when trying to work with iOS SwiftUI, but I can confirm that this issue is also present in the macOS one (in this repo), and this issue IS NOT present in the other (non SwiftUI) demo app.

First, there is an Call to main actor-isolated initializer 'init(cursor:)' in a synchronous nonisolated context error in Neon TreeSitterClient. I solved (bypassed?) this issue by adding @MainActor to the struct ContentView: View of the demo app.

However, then the TreeSitterResource/TreeSitterLanguage.swift gives No such module 'tree_sitter' at import tree_sitter, and if I replace this by import TreeSitter (like what have been changed in SwiftTreeSitter commit b39502d, I'm not sure if I looked at the right thing though), the error Cannot find type 'TSLanguage' in scope is shown at public var parser: UnsafePointer<TSLanguage>.

I am not sure if this is also related to some issue in Neon and/or SwiftTreeSitter and/or other dependencies, and I hope that by posting this here you might be able to give some suggestions on which direction can I look for to solve this.

[krzyzanowskim]

there is an Call to main actor-isolated initializer 'init(cursor:)' in a synchronous nonisolated context error in Neon TreeSitterClient

I'm not sure how to address that "properly" to please Swift Concurrency Gods. I'm ok to fallback to @preconcurrency if needed. I will summon @mattmassicotte from Neon and SwiftTreeSitter projects here in case he can chip in with advice.

[krzyzanowskim]

gives No such module 'tree_sitter' at import tree_sitter

I fixed that part.

[mattmassicotte]

This is an unfortunate bug in the Neon 0.6 release. The Swift 5 compiler isn't able to catch it, but the Swift 6 compiler (Xcode 16) does. I do not see how annotating the view with MainActor could help, as the view is already MainActor, and the problem isn't in that type...

I'm actively working on a big new release of Neon now. I hate to make you do this, as I think there are still some bugs in there, but it might be easier to just move to the main branch now.

[Qubik65536]

I do not see how annotating the view with MainActor could help, as the view is already MainActor, and the problem isn't in that type...

I also don't see how this works, but I am able to constantly reproduce this, both when building for Mac (My Mac, M2 Pro, macOS 15.2 (24C101)) and iOS (iOS 18.2 (22C150) Simulator).

Test on Xcode 16.2.0, macOS 15.2 (24C101):

1. Project in the way cloned as it is.
2. Clean the build folder.
3. Attempt to build.
4. Call to main actor-isolated initializer 'init(cursor:)' in a synchronous nonisolated context at https://github.com/ChimeHQ/Neon/blob/7df7d080a271cfa4dc87f94cccc024665a75047e/Sources/TreeSitterClient/TreeSitterClient.swift#L449-L453 (.map({ ResolvingQueryCursor(cursor: $0) }))
5. Annotate @MainActor the struct ContentView: View of the DemoAppSwiftUI project.
6. Clean the build folder again (or not, this actually doesn't matter much in my experiments).
7. Attempt to build again, and the error mentioned above is gone.

And if I remove the annotation and restart again, this can be reproduced over and over again.

---

Edit:

I referred to https://stackoverflow.com/questions/78804195/swiftui-error-call-to-main-actor-isolated-initializer-init-in-a-synchronous when I tried to fix this, and this comments draw my attention just when I check it again now.

> If ContentView itself is already on MainActor for iOS 18+, why do I still need to mark it with @MainActor?
    – Shuaiqing Luo Commented Jul 28 at 17:18
> @ShuaiqingLuo because you are targeting less than that now. So the initializer for the model assumes nonisolated.
    – lorem ipsum Commented Jul 28 at 17:31

Is this maybe the reason why "as the view is already MainActor" may not be true?

[mattmassicotte]

Static isolation cannot be conditional on runtime environment. It is a compile-time construct. So, I don't think that stack overflow discussion makes complete sense.

But, I have tried to reproduce what you have done and am unable. The build failure within Neon, for me, is unaffected by the redundant @MainActor annotation on that ContentView.

[Qubik65536]

Static isolation cannot be conditional on runtime environment. It is a compile-time construct. So, I don't think that stack overflow discussion makes complete sense.

Got it.

But, I have tried to reproduce what you have done and am unable. The build failure within Neon, for me, is unaffected by the redundant @MainActor annotation on that ContentView.

I will try to test with a new empty project later and see if this is an issue that is just in the STTextView-Plugin-Neon demo app.

[krzyzanowskim]

I'm actively working on a big new release of Neon now. I hate to make you do this, as I think there are still some bugs in there, but it might be easier to just move to the main branch now.

@mattmassicotte, I checked it, and there have been significant API changes. I would rather wait for any release than bind to the main branch obviously.

[mattmassicotte]

Yes as you can see my releases are a real sign of quality...

But, more seriously, I'm sorry this happened. It's embarrassing. I'm hopeful I'll be able to produce a new release of Neon fairly soon.

[Qubik65536]

Hello, I am back working on the iOS port :)

Bad news... it seems to me that even with 7092849, this is still broken (or I'd say even more broken as @MainActor is no longer a working workaround)... Is it still something that only I have? Any advice for me to try something for this?

[krzyzanowskim]

we can go whatever it needs to be sto workaround, including nonisolated(unsafe) if needed

[Qubik65536]

Now it is... sort of fixed.

All I had to do is:

+ @MainActor
+ @preconcurrency
public final class TreeSitterClient {

in Neon, and the issue is gone for now...

These are added already by @mattmassicotte in Neon's main branch (code), however it is for sure not in the version we use as dependency here.

For now I can just use a local, modified Neon dependency to work on my iOS stuff, but I guess this is also something that needs to be sort out later if we're staying with Neon 0.6 for a while since this local stuff will make things pretty messy for other people.

[mattmassicotte]

Unfortunately, I don't think there is any way to fix this issue aside from modifying the code within Neon as you have done. I think it should be possible to make a 0.6.1 release off a branch that contains that fix...

[Qubik65536]

Unfortunately, I don't think there is any way to fix this issue aside from modifying the code within Neon as you have done. I think it should be possible to make a 0.6.1 release off a branch that contains that fix...

IMO it would be great if a 0.6.1 can be made before we all move to the next release.