Fix cl.exe being excluded for .c files and c/cpp caching. #9544
Conversation
| const compiler_condition: (info: configs.KnownCompiler) => boolean = info => | ||
| ( | ||
| // Filter out c compilers for cpp files and vice versa, except for cl.exe, which handles both. | ||
| path.basename(info.path) === "cl.exe" || |
There was a problem hiding this comment.
This check fixes cl.exe not appearing for .c files.
| private async loadDetectedTasks(): Promise<void> { | ||
| if (!DebugConfigurationProvider.detectedBuildTasks || DebugConfigurationProvider.detectedBuildTasks.length === 0) { | ||
| DebugConfigurationProvider.detectedBuildTasks = await cppBuildTaskProvider.getTasks(true); | ||
| const editor: vscode.TextEditor | undefined = vscode.window.activeTextEditor; |
There was a problem hiding this comment.
These checks are taken from the start of getTask -- I didn't see a good way to refactor it so I didn't bother.
| return; | ||
| } | ||
|
|
||
| if (fileIsCpp) { |
There was a problem hiding this comment.
This fixes the same detectedBuildTasks cache being used for c and cpp.
There was a problem hiding this comment.
One way is not to keep a cache and always load the tasks. It may help when a new compiler is being installed in the middle of a session. I added this cache so that we don't keep getting the tasks over and over again, but now I am not sure that it was the right decision. Which way you think is better? to keep the cache or to always load the tasks?
There was a problem hiding this comment.
I don't know. Using caches seems fine to me -- I see the cache get hit 2 times for every debug invocation and it's possible the list of compilers could be big, so it's hard to say how long that could potentially add to debug startup time. Installing a new compiler in the middle of a sessions seems pretty rare, and a user who did that and didn't see the new compiler added would probably guess they might need to reload VS Code.
I hit these bugs while investigating #9535 .