Fix Windows binary path links in output log by appending .exe extension

[Copilot]

• Understand the issue: On Windows, clicking paths without .exe extension in the output log causes "Unable to open 'app'" error because the actual file is app.exe
• Investigate the codebase and find the relevant code in src/parser.ts
• Fix: Add logic to append .exe extension on Windows when:
  • The binary path is extracted from -o or /out switches
  • The path has no extension
  • This applies to both linkerTargetBinary and compilerTargetBinary paths from /Fe switch
• Verified that the fix doesn't affect Linux/Mac (the condition only applies when process.platform === "win32")
• Verified that path.extname() correctly returns empty string for paths without extension
• Run code review (addressed feedback: added clarifying comment)
• Run CodeQL security scan (no issues found)
• Add unit tests for binary path extension handling logic

Changes made:

1. Modified src/parser.ts to append .exe extension on Windows when:

   • Binary path from /Fe compiler switch has no extension (inside existing process.platform === "win32" block)
   • Binary path from -o or /out linker switches has no extension (with explicit platform check)

2. Added unit tests in src/test/fakeSuite/extension.test.ts:

   • Tests for path.extname behavior with paths without extension
   • Tests for path.extname behavior with paths with extension
   • Tests for the extension-appending logic pattern

Note: The Windows (mingw) test baselines may need to be updated when tests are run on Windows, as they currently reflect the old behavior without .exe extension. This is expected behavior since the fix corrects the issue.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>There's an error dialog pops up and the meessage for: "Unable to open 'appʼ The editor could not be opened because the file was not found." when clicking the app.exe path</issue_title>
<issue_description>Environment: VSCode 1.97.2+ Makefile Tools v0.12.17(Preview)

More info:

1. Repro platform: Windows
2. Linux & Mac platforms don't repro this issue

Repro steps:

1. Clone the makefile project (such as: https://github.com/remonbonbon/makefile-example) and open it in VSCode
2. Press "Ctrl+," to open the VS Code settings page
3. Search "makefile.extensionOutputFolder" and switch to Workspace, then set Makefile:Extension Output Folder to “.vscode”, then save.
4. Double click Makefile.file and change the codes.

Original:

        SRCS  = $(shell find ./src     -type f -name *.cpp)
	HEADS = $(shell find ./include -type f -name *.h)

Updated to:

          SRCS = src/main.cpp src/mod/mod.cpp
	  HEADS = include/main.h include/mod/mod.h

5. Open the "Makefile Tools Project Outline" , set the Build target to “all” and set the Launch target to "……app()".
6. Open the .vscode->setting.json and add below codes and save.

	 "MIMode": "gdb",
	 "miDebuggerPath": "C:\\msys64\\mingw64\\bin"

7. Click Makefile icon and open the Makefile Tools Project Outline, then debug using the debug icon.
8. Observe the Makefile Tools output log and find the line: "program = c:\Users\v-ashli\makefile-example\app (= c:\Users\v-ashli\makefile-example\app)"
9. Press "Ctrl+Click" and open the app.exe and observe.

Expected result:
There is a warning message for: "The file is not displayed in the text editor because it is either
binary or uses an unsupported text encoding."

Such as Linux platform:

Actual result:
There's an error dialog pops up and the meessage for: "Unable to open 'appʼ The editor could not be opened because the file was not found."
</issue_description>

<agent_instructions>Please also add tests if it makes sense to.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes There's an error dialog pops up and the meessage for: "Unable to open 'appʼ The editor could not be opened because the file was not found." when clicking the app.exe path #698

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[snehara99]

@copilot are any new tests to cover the scenario possible?

[Copilot]

@copilot are any new tests to cover the scenario possible?

Added unit tests in commit 88755aa. The tests cover the path.extname behavior for various path formats and the extension-appending logic pattern used in the fix. Note that the actual parseLaunchConfigurations function in parser.ts is deeply integrated with VS Code APIs and file system operations, making direct unit testing challenging without significant mocking infrastructure. The added tests validate the core logic that the fix relies on.