Unable to rename and reference variables passed to a method that is roslyn source generated.

[Efaideleon]

Hi, I'm using the plugin for Unity Dots. A lot of the code there is source generated.
Whenever I try to rename a variable that is passed to one of the methods that is source generated,
I get the following error: (using vim.lsp.buf.rename)

[ERROR][2025-03-14 11:22:03] ...lsp/handlers.lua:623	
"[LanguageServerHost] System.InvalidOperationException: Unexpected null - file ConflictResolver.cs line 292\n   
at Microsoft.CodeAnalysis.Contract.Fail(String message, Int32 lineNumber, String filePath) in /_/src/Dependencies/Contracts/Contract.cs:line 159\n   
at Microsoft.CodeAnalysis.Rename.ConflictEngine.ConflictResolver.AddDeclarationConflictsAsync(ISymbol renamedSymbol, ISymbol renameSymbol, IEnumerable`1 referencedSymbols, MutableConflictResolution conflictResolution, IDictionary`2 reverseMappedLocations, CancellationToken cancellationToken) in /_/src/Workspaces/Core/Portable/Rename/ConflictEngine/ConflictResolver.cs:line 292\n
at Microsoft.CodeAnalysis.Rename.ConflictEngine.ConflictResolver.Session.IdentifyConflictsAsync(HashSet`1 documentIdsForConflictResolution, IEnumerable`1 allDocumentIdsInProject, ProjectId projectId, MutableConflictResolution conflictResolution, ImmutableHashSet`1 conflictLocations) in /_/src/Workspaces/Core/Portable/Rename/ConflictEngine/ConflictResolver.Session.cs:line 456\n
at Microsoft.CodeAnalysis.Rename.ConflictEngine.ConflictResolver.Session.ResolveConflictsAsync() in /_/src/Workspaces/Core/Portable/Rename/ConflictEngine/ConflictResolver.Session.cs:line 145\n   
at Microsoft.CodeAnalysis.Rename.ConflictEngine.ConflictResolver.ResolveSymbolicLocationConflictsInCurrentProcessAsync(SymbolicRenameLocations renameLocations, String replacementText, ImmutableArray`1 nonConflictSymbolKeys, CancellationToken cancellationToken) in /_/src/Workspaces/Core/Portable/Rename/ConflictEngine/ConflictResolver.cs:line 107\n
at Microsoft.CodeAnalysis.Rename.ConflictEngine.ConflictResolver.ResolveLightweightConflictsAsync(ISymbol symbol, LightweightRenameLocations lightweightRenameLocations, String replacementText, ImmutableArray`1 nonConflictSymbolKeys, CancellationToken cancellationToken) in /_/src/Workspaces/Core/Portable/Rename/ConflictEngine/ConflictResolver.cs:line 85\n
at Microsoft.CodeAnalysis.LanguageServer.Handler.RenameHandler.GetRenameEditAsync(Document document, LinePosition linePosition, String newName, CancellationToken cancellationToken) in /_/src/LanguageServer/Protocol/Handler/Rename/RenameHandler.cs:line 56\n
at Microsoft.CommonLanguageServerProtocol.Framework.QueueItem`1.StartRequestAsync[TRequest,TResponse](TRequest request, TRequestContext context, IMethodHandler handler, String language, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/QueueItem.cs:line 191"

Also when I use the LSP to look up references (using vim.lsp.buf.references) for a variable passed to a method that is source generated I get the following error:

Error executing vim.schedule lua callback: BufReadCmd Autocommands for "roslyn-source-generated://*": Vim(append):Error executi
ng vim.schedule lua callback: ...on/.local/share/nvim/lazy/roslyn.nvim/lua/roslyn/lsp.lua:142: Vim:Error executing vim.schedule
 lua callback: ...vim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/handlers.lua:16: Vim:roslyn: -32000: Syntax tree doesn't belong t
o the underlying 'Compilation'. (Parameter 'model')
stack traceback:
        [C]: in function 'nvim_command'
        ...vim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/handlers.lua:16: in function 'err_message'
        ...vim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/handlers.lua:732: in function 'handler'
        ...eovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>
        [C]: in function 'wait'
        ...on/.local/share/nvim/lazy/roslyn.nvim/lua/roslyn/lsp.lua:159: in function <...on/.local/share/nvim/lazy/roslyn.nvim/
lua/roslyn/lsp.lua:122>
        [C]: in function 'bufload'
        .../neovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/util.lua:276: in function 'get_lines'
        .../neovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/util.lua:1913: in function 'locations_to_items'
        ...vim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/handlers.lua:254: in function 'handler'
        ...eovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>
stack traceback:
        [C]: in function 'nvim_buf_set_lines'
        ...on/.local/share/nvim/lazy/roslyn.nvim/lua/roslyn/lsp.lua:142: in function 'handler'
        ...eovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>
        [C]: in function 'wait'
        ...on/.local/share/nvim/lazy/roslyn.nvim/lua/roslyn/lsp.lua:159: in function <...on/.local/share/nvim/lazy/roslyn.nvim/
lua/roslyn/lsp.lua:122>
        [C]: in function 'bufload'
        .../neovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/util.lua:276: in function 'get_lines'
        .../neovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/util.lua:1913: in function 'locations_to_items'
        ...vim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/handlers.lua:254: in function 'handler'
        ...eovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>
stack traceback:
        [C]: in function 'bufload'
        .../neovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/util.lua:276: in function 'get_lines'
        .../neovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/util.lua:1913: in function 'locations_to_items'
        ...vim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/handlers.lua:254: in function 'handler'
        ...eovim/0.10.4_1/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

I'm using neovim 0.10.4 but the error also happens in neovim nightly.
I also tried both Microsoft.CodeAnalysis.LanguageServer v4 and v5 and .Net SDK 6, 7, 8, 9, and 10 preview and the error still happens.

I always make sure to save all the buffers and do domain reloading in Unity but I keep getting the same errors.

[seblyng]

Is this working in vscode?

[Efaideleon]

It does seem to be working in vscode. I've noticed that when I click FindAllReferences in vscode it doesn't include the roslyn source generated files, but when I lookup the references for the same variable that is passed to a source generated method in neovim, and it does work, it does include the roslyn source generated files.

I say when 'it does work' because sometimes when I try to look up the references and I get error, I would try running the command again and again until it does show the references in the quickfix list. I haven't figured out why sometimes it works and sometimes it doesn't.

These are pictures showing the difference between finding references in vscode vs neovim for that variable:

[seblyng]

Hmm, I have never really worked with source generated files myself so I am not sure... Tagging @zickb since you had the PR for source generated files in case you have any idea or have noticed this😅

[zickb]

I've had a quick look, but I don't recall seeing these errors before.
It looks like the roslyn lsp server has a problem finding the compilation/project the sg file belongs to.

It would be nice if you could provide a minimal project in which the errors can be produced.

As mentioned in #115, I suspect there is somewhere a small difference in the setup/startup logic in the lsp clients that leads to different roslyn lsp server states.

You could also try navigating to a sg file first (go to definition) and then switching back to your file and renaming the symbol.
(At least this will fix the difference noted in #115).

[zickb]

A small note: Vscode also includes the sg files in the find all references result. The sg files are the unmodified files in the vscode screenshot. But vscode displays the file path differently to the user.
If you want a similar experience in nvim, you have to configure it. I described a telescope setup with improved sg file display in #115.

[Efaideleon]

Hi,
oh you are right I completely missed that.

I have a small project to replicate the bug on.

• I run dotnet clean and dotnet build on MyGeneratorProject directory where the SimpleComponentGenerator.cs file is.
• Then also run the same commands in the DemoProject directory where the Program.cs file is, and I compile Program.cs with dotnet run.
• Then I open nvim and wait for the Roslyn project initialization to complete.
• I run the find references command vim.lsp.buf.references on the TestLoggerComponent class on line 7 in Program.cs and it displays the references in the quick fix list, but then I try to rename the same class using vim.lsp.buf.rename and I get the ConflictResolver.cs error.

I also tried going to the roslyn-source-generated from the quickfix list and then gd back and rename the same class but I also get the same error. As for the references bug, it still appears on that same DemoProject but I haven't figured out how to replicate it consistently.

DemoProject Github Link

https://github.com/Efaideleon/DemoProjectsg.git

[Efaideleon]

Now I understand that I was wrong. It's not a problem with a variable being passed to a source generated function, but rather the source generated code referencing something like a class or struct.

[radiKal07]

I want to rename a variable in my own class and I get a similar error:

roslyn: -32000: Unexpected null - file ConflictResolver.cs line 240