fix: Fixed an issue with DAP code fragment creation for languages with dialects (fixes #1118 and #1456)#1466
Conversation
…'s one with a different base language, and the base language is used in that case. Otherwise the file type is used.
…rrect change plus unit tests to verify the standard and dialect behaviors.
| // Get file type / language of the file which is debugging when debugger is suspended. | ||
| fileType = file.getFileType(); | ||
| language = file.getLanguage(); | ||
| // If the file's language is a more specific dialect of the file type's language, degrade to the file type's |
There was a problem hiding this comment.
This is the main logic change for the fix. It basically does what's described in the PR itself.
| import com.intellij.testFramework.LightPlatformTestCase; | ||
| import com.intellij.testFramework.LightVirtualFile; | ||
|
|
||
| public class DAPDebuggerEditorsProviderTest extends LightPlatformTestCase { |
There was a problem hiding this comment.
Added tests to verify the original behavior for simple file types with a single language and the corrected behavior for more complex file types that can have multiple dialects of a language.
| assertEquals(PlainTextLanguage.INSTANCE, codeFragment.getLanguage()); | ||
| } | ||
|
|
||
| public void testWithDialectLanguage() { |
There was a problem hiding this comment.
I use JSON here because it already has a JSON5 dialect/variant, though it still operates differently than the JavaScript ones because for JSON, there's a 1:1 correspondence between file types (JsonFileType and Json5FileType) and languages (JsonLanguage and Json5Language) whereas for JavaScript, there's a single JavaScriptFileType for all of the languages/dialects. So using JSON almost gets me to a reproduction, but there's one thing I have to do explicitly in this test to model the JavaScript behavior.
| // Create a file with the dialect language | ||
| PsiFile dialectFile = PsiFileFactory.getInstance(getProject()).createFileFromText("test.json", Json5Language.INSTANCE, "{}"); | ||
| VirtualFile dialectVirtualFile = dialectFile.getVirtualFile(); | ||
| // Force the file type to be the base instead of the one inferred from the dialect language used above |
There was a problem hiding this comment.
And that one thing is right here. At this point, the file type of dialectFile is Json5FileType, inferred from Json5Language used when creating the file. That won't reproduce the original behavior/issue, though, but thankfully I can set the file type explicitly on the underlying LightVirtualFile so that it does in fact model the JavaScript-like behavior of a single file type that can have multiple languages, all but one of which don't match the file type's own reported language.
| DAPDebuggerEditorsProvider debuggerEditorsProvider = new DAPDebuggerEditorsProvider(MockLanguageFileType.INSTANCE, null); | ||
|
|
||
| // If the original issue exists, this will fail with "JSON5 doesn't participate in view provider..." | ||
| PsiFile codeFragment = debuggerEditorsProvider.createExpressionCodeFragment(getProject(), "", dialectFile, true); |
|
As usual, great work! Thanks so much @SCWells72 ! |
2 participants
If the file's language is a more specific dialect of the file type's language, the less specific language is used for the code fragment. Otherwise the original error will be raised when the file's view provider doesn't support the dialect variant.