`DAPExpressionCodeFragment` constructor can create a file that cannot be used for languages with dialects

[SCWells72]

The IDE's native JavaScript language has dialects, e.g.:

Different dialects can be used for different files with the same extension in different project directories:

Now this may seem contrived, but since IntelliJ IDEA 2026.1 includes native support for JavaScript/TypeScript/CSS but not support for the JavaScript debugger, LSP4IJ + vscode-js-debug provides a nice way to address that gap. However, if a *.js file is evaluated as being ES6 by the IDE, the resulting DAPExpressionCodeFragment can end up evaluated as being base JavaScript, and this results in the following runtime error:

java.lang.AssertionError: Language Language: ECMAScript 6 doesn't participate in view provider com.intellij.psi.SingleRootFileViewProvider{vFile=LightVirtualFile: \DAPExpressionCodeFragment.js, content=VirtualFileContent{size=0}, eventSystemEnabled=true}: [Language: JavaScript]
	at com.intellij.extapi.psi.PsiFileBase.findLanguage(PsiFileBase.java:48)
	at com.intellij.extapi.psi.PsiFileBase.<init>(PsiFileBase.java:23)
	at com.redhat.devtools.lsp4ij.dap.evaluation.DAPExpressionCodeFragment.<init>(DAPExpressionCodeFragment.java:39)
	at com.redhat.devtools.lsp4ij.dap.DAPDebuggerEditorsProvider.createExpressionCodeFragment(DAPDebuggerEditorsProvider.java:77)
	at com.redhat.devtools.lsp4ij.dap.DAPDebuggerEditorsProvider.createExpressionCodeFragment(DAPDebuggerEditorsProvider.java:70)
	at com.intellij.xdebugger.evaluation.XDebuggerEditorsProviderBase.createExpressionCodeFragment(XDebuggerEditorsProviderBase.java:54)
	at com.intellij.xdebugger.evaluation.XDebuggerEditorsProviderBase.createDocument(XDebuggerEditorsProviderBase.java:43)
	at com.redhat.devtools.lsp4ij.dap.DAPDebuggerEditorsProvider.createDocument(DAPDebuggerEditorsProvider.java:53)
	at com.intellij.xdebugger.evaluation.XDebuggerEditorsProviderBase.createDocument(XDebuggerEditorsProviderBase.java:34)
	at com.intellij.xdebugger.impl.ui.XDebuggerEditorBase.createDocument(XDebuggerEditorBase.java:359)
	at com.intellij.xdebugger.impl.ui.XDebuggerExpressionComboBox.createDocument(XDebuggerExpressionComboBox.java:168)
	at com.intellij.xdebugger.impl.ui.XDebuggerExpressionComboBox.lambda$doSetText$0(XDebuggerExpressionComboBox.java:150)

The solution should be to change the way the file is created to use the original file's language instead of its file type, specifically by changing DAPExpressionCodeFragment's constructor from:

new LightVirtualFile("DAPExpressionCodeFragment." + fileType.getDefaultExtension(), fileType, text)),

to:

new LightVirtualFile("DAPExpressionCodeFragment." + fileType.getDefaultExtension(), language, text)),

Note the change from fileType to language when creating the LightVirtualFile. The main potential issue would be if in the process of debugging, files from multiple dialects are included. The alternative would be to use the common base language for the code fragment which, while a least common denominator approach, would be safe for all potential dialects that might come into play during the debugging session.

[SCWells72]

Actually I did just confirm that fix. I'll see if I can get a minimal PR going for it shortly if possible. No guarantees as I have an afternoon spring break field trip with the kids planned.

[SCWells72]

Ugh. I'm not sure if that will work since a common scenario will be that the language will be PlainTextLanguage or TextMateLanguage which won't support language features. I think it needs to create the LightVirtualFile based on one or the other conditionally. Let me see what I can do...

[angelozerr]

It is the same issue than #1118

[SCWells72]

I'm putting together a quick PR that creates the LightVirtualFile based on the language's base language if it's a language with dialects and with the file type if not. I'll see if I can get that going before my early afternoon spring break outing with my kids.

[angelozerr]

@SCWells72 I have not tested, but what do you think about thtis code:

@Override
    protected PsiFile createExpressionCodeFragment(@NotNull Project project,
                                                   @NotNull String text,
                                                   @Nullable PsiElement context,
                                                   boolean isPhysical) {
        FileType fileType = getFileType();
        Language language = Language.ANY;
        // File should be never null here
        PsiFile file = context != null ? context.getContainingFile() : null;
        if (file != null) {
            // Get file type of the file which is debugging when debugger is suspended.
            fileType = file.getFileType();
        }
        // Get the language from the file type to ensure compatibility with the ViewProvider
        if (fileType instanceof com.intellij.openapi.fileTypes.LanguageFileType) {
            language = ((com.intellij.openapi.fileTypes.LanguageFileType) fileType).getLanguage();
        }
        return createExpressionCodeFragment(project, text, fileType, language);
    }

[SCWells72]

@angelozerr, what I have is this:

    public DAPExpressionCodeFragment(@NotNull CharSequence text,
                                     @NotNull FileType fileType,
                                     @NotNull Language language,
                                     @Nullable DAPDebugProcess debugProcess,
                                     @NotNull Project project) {
        super(new SingleRootFileViewProvider(PsiManager.getInstance(project),
                createLightVirtualFile(text, fileType, language)),
                language);
        this.fileType = fileType;
        this.debugProcess = debugProcess;
        ((SingleRootFileViewProvider) getViewProvider()).forceCachedPsi(this);
    }

    @NotNull
    private static LightVirtualFile createLightVirtualFile(@NotNull CharSequence text,
                                                           @NotNull FileType fileType,
                                                           @NotNull Language language) {
        String codeFragmentFilename = "DAPExpressionCodeFragment." + fileType.getDefaultExtension();

        // If this is a dialect, use the base language so that the code fragment supports all dialects needed during
        // debugging, even if in a least common denominator manner
        Language baseLanguage = language.getBaseLanguage();
        if ((baseLanguage != null) && !baseLanguage.is(language)) {
            return new LightVirtualFile(codeFragmentFilename, baseLanguage, text);
        } else {
            return new LightVirtualFile(codeFragmentFilename, fileType, text);
        }
    }

but I've also run out of time for today. I'll try to get back to it sometime soon if possible, but between my kids' spring break and a conference next week, my "spare" time is pretty scarce.

[SCWells72]

@angelozerr, the bad news is that we didn't get to have our spring break outing this afternoon for...reasons. The good news is that afforded time to work on this as PR #1466. Note that I have only confirmed that it fixes the JavaScript issue I logged here and not the Go issue in #1118.

[angelozerr]

@angelozerr, the bad news is that we didn't get to have our spring break outing this afternoon for...reasons.

Hope you will find again to enjoy with your kids.

The good news is that afforded time to work on this as PR #1466. Note that I have only confirmed that it fixes the JavaScript issue I logged here and not the Go issue in #1118.

Thanks so much @SCWells72 ! LSP4IJ 0.19.3 has been released and hosts your fix.