You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GCC linker errors not showing up in Problems window #2864
This would be a bug/feature request. We have a regular expression that matches compiler errors, but the linker errors don't match that pattern. Thanks for reporting it. We may not get to this immediately, but will accept a PR from the community if someone is able to address it before we do.
I believe that all the problem matchers are active when you build with our commands (not tasks). You can control which ones are active with the cmake.enabledOutputParsers setting.
It is because the VSCode does not provide an API to show the problems without of a file path. I meant, that usually, the linker errors does not a file paths at all.
It can show problems using a 'null' path. Besides that, the file path is provided by the linker and should be matched by the regex (/Volumes/.../main.c:105 in this case).
I am currently using an additional problemmatcher for linker errors which works fine.
Besides that, the file path is provided by the linker
This is a special case that there is a path to the file. In most cases, linking errors do not contain any paths. This will not only affect GCC but also other compilers (eg MSVC, IAR, KEIL, SDCC and etc).
So, in a common case you can't extract the file property for the problem matcher... And, what's to do in such case is unknown..
What you can do in such a case is use a 'null' path for the file.
In my opinion, this is currently the best way to report linker errors without file reference. Not reporting linker errors is really not a good option for most users. In the future, I hope VS Code will implement a way to implement error reporting without file reference.
Hmm.. Is it possible at all to set a null path? Because the vscode.DiagnosticCollection expects the the method set(uri: Uri, diagnostics: readonly Diagnostic[]): void use an vscode.Uri type. I'm not sure that it is possible to assign a null to the Uri (I'm not a typescript expert at all).
It turns out there already is a GNU linker error parser in your code base.
The CI unit test in my PR #3950 failed because the unit test for this linker error parser failed. It now fails because my GCC error parser already finds linker errors, which resulsts in the linker error parser not being executed,
It turns out you guys have a bug that causes errors that are detected by the linker error parser to not be pushed to the Problems View (short description of the bug: default configuration string for linker parser is "gnuld", but code uses "link", so linker errors are ignored in the function resolveDiagnostics) .
If fixed this bug locally by changing the string "link" to "gnuld".
Then errors detected by the linker error parser are shown in the Problems View. But the parsing does not work properly. It is too simplistic. It only detects 6 out of the 12 linker errors I use for testing, and 3 out of these 6 findings are parsed incorrectly (e.g. path/to/ld.exe:path/to/file:138: syntax error is detected, but the file name path/to/ld.exe:path/to/file is parsed instead of path/to/file).
So I suggest I fix the described bug and move the linker errors that I implemented in the GCC parser to the linker parser, and also add some unit tests for all the error strings I use for testing.
I also would like to test this new solution at work for a few weeks to make sure I did not break anything.
I think I need to test it for a while because the parsing order is actually relevant. E.g. a linker error of type path/to/ld[.exe]:path/to/file:line: warning: memory region ... not declared would be falsely detected as a GCC compiler error of type path/to/file:line: severity: message` if the compiler errors are parsed prior to the linker errors. I already regarded this in my local fix by changing the parser execution order (linker parser is now executed before the compiler parser). But I prefer to test this a little further.
Are you guys fine with that or do you prefer my current solution with linker error parsing in the GCC parser and want to delete the separate linker error parser?
RolfNoot I created a new branch in my forked repo, see branch dev/0xemgy/FixGnuLdProblemsViewPrompthere, with the solution I'm confident Garrett Campbell (@gcampbell-msft) will prefer (keeping the gnu ld parser).
Installed the extension manually, overwriting the latest release:
Made sure my code is really in the main.js of the extension now running (see "C:\Users\my_username.vscode\extensions\ms-vscode.cmake-tools-99.99.0\dist\main.js":
Tested it with just one warning (will test it extensively in the following weeks):
Undefined reference is detected successfully.
I also updated the typescript playground code where I tested the regex stuff over the last couple of months (see here).
So at first glance looking good, but since I am not proficient at all with typescript and desktop applications in general, I might have overlooked something. Looking forward to your feedback!
Garrett Campbell (@gcampbell-msft) I was able to test my changes extensively over the last 3 weeks at work. I also added a few unit tests and cleaned up the regex expressions. For my use cases it is working properly. It is commited in the PR 3950 and is ready for review.
Of course, feedback of RolfNoot would be much appreciated.
RolfNoot We're in the process of verifying this issue, but we're not sure if the issue has been fixed, can you help us determine this by looking at the information below? If it's not correct, would you be able to provide us with a reproduction project?
The error message provided by RolfNoot occurs in the Problem window after the fix.
Its is /Volumes/Data/VScode/Gatewise_AddOn01/source/main.c:105: undefined reference to 'no_reference'.
The message you get in the gif has a different format: C:/Users/v-cathyzhang/Desktop/CMAKE/main.cpp:4:(.text+0xe): undefined reference to 'someFunction()'.
The difference is marked in bold. After the line number, you additionally get section and offset of the line.
This format is currently not supported, so the message does not get parsed.
Running your example zip, I get the message format without the section, which is correctly parsed:
Since you are using mingw version 14.2.0, and I use 13.1.0, I assume the output format might have changed.
Support for such formats could easily be added to the error parser if desired.
Even after updating gcc to version 14.2.0, I don't get the linker error format with the extra section info.
When I used Unix Makefiles as a generator, I found that my gnuld modifications caused false positive make errors. I only used Ninja before, and the unit test that was already there only checks for false positives with the gcc parser, not the gnuld parser, so I didn't run into this problem then.
When I use Ninja as the generator again, the "undefined reference" error doesn't get parsed anymore, even without the extra section info. This is due to a trailing "\r". I'm not sure if this was the case before.
After some more messing around, it turns out that another linker error, the one for "multiple definitions", is still detected, but parsed incorrectly now. It looks like the format has changed, or maybe I manually tested with the wrong format a few months ago and did not try to provoke the error with a build.
If we're going to fix 1, I'd probably need some settings to get those output formats with the extra section info. Otherwise, I could just assume the format seen in the GIF.
Hope that works for now. How do you want to proceed?
Activity
bobbrow commentedon Nov 22, 2022
This would be a bug/feature request. We have a regular expression that matches compiler errors, but the linker errors don't match that pattern. Thanks for reporting it. We may not get to this immediately, but will accept a PR from the community if someone is able to address it before we do.
RolfNoot commentedon Nov 22, 2022
Thanks for the quick reply. Where (in code?) can I find this regex? I might change it according my needs.
bobbrow commentedon Nov 22, 2022
It is here:
vscode-cmake-tools/src/diagnostics/gcc.ts
Line 9 in a00c339
RolfNoot commentedon Nov 23, 2022
Changing the regex doesn't affect the output. I changed the one in
vscode-cmake-tools/src/diagnostics/msvc.tswhich seems to affect the output.How can I select the problemMatcher when starting build programmatically (not using Tasks)
vscode.commands.executeCommand('cmake.build')?bobbrow commentedon Nov 23, 2022
I believe that all the problem matchers are active when you build with our commands (not tasks). You can control which ones are active with the
cmake.enabledOutputParserssetting.evakili commentedon Jan 4, 2023
This issue also exists in MSVC builds. MSVC link errors are not matched by the problem matcher.
denis-shienkov commentedon Feb 3, 2023
It is because the VSCode does not provide an API to show the problems without of a file path. I meant, that usually, the linker errors does not a file paths at all.
RolfNoot commentedon Feb 3, 2023
It can show problems using a 'null' path. Besides that, the file path is provided by the linker and should be matched by the regex (/Volumes/.../main.c:105 in this case).
I am currently using an additional problemmatcher for linker errors which works fine.
This should be implemented in the extension IMHO.
denis-shienkov commentedon Feb 4, 2023
This is a special case that there is a path to the file. In most cases, linking errors do not contain any paths. This will not only affect GCC but also other compilers (eg MSVC, IAR, KEIL, SDCC and etc).
So, in a common case you can't extract the
fileproperty for the problem matcher... And, what's to do in such case is unknown..I even created an issue about that:
but all was unsucessfull.
RolfNoot commentedon Feb 4, 2023
What you can do in such a case is use a 'null' path for the file.
In my opinion, this is currently the best way to report linker errors without file reference. Not reporting linker errors is really not a good option for most users. In the future, I hope VS Code will implement a way to implement error reporting without file reference.
denis-shienkov commentedon Feb 4, 2023
Hmm.. Is it possible at all to set a null path? Because the vscode.DiagnosticCollection expects the the method
set(uri: Uri, diagnostics: readonly Diagnostic[]): voiduse anvscode.Uritype. I'm not sure that it is possible to assign anullto theUri(I'm not a typescript expert at all).15 remaining items
0xemgy commentedon Aug 1, 2024
Garrett Campbell (@gcampbell-msft) v-frankwang I think I got it: Forked the repo, created a PR, agreed to the CLA: #3950
0xemgy commentedon Aug 3, 2024
Garrett Campbell (@gcampbell-msft) v-frankwang
It turns out there already is a GNU linker error parser in your code base.
The CI unit test in my PR #3950 failed because the unit test for this linker error parser failed. It now fails because my GCC error parser already finds linker errors, which resulsts in the linker error parser not being executed,
It turns out you guys have a bug that causes errors that are detected by the linker error parser to not be pushed to the Problems View (short description of the bug: default configuration string for linker parser is "gnuld", but code uses "link", so linker errors are ignored in the function
resolveDiagnostics) .If fixed this bug locally by changing the string "link" to "gnuld".
Then errors detected by the linker error parser are shown in the Problems View. But the parsing does not work properly. It is too simplistic. It only detects 6 out of the 12 linker errors I use for testing, and 3 out of these 6 findings are parsed incorrectly (e.g.
path/to/ld.exe:path/to/file:138: syntax erroris detected, but the file namepath/to/ld.exe:path/to/fileis parsed instead ofpath/to/file).So I suggest I fix the described bug and move the linker errors that I implemented in the GCC parser to the linker parser, and also add some unit tests for all the error strings I use for testing.
I also would like to test this new solution at work for a few weeks to make sure I did not break anything.
I think I need to test it for a while because the parsing order is actually relevant. E.g. a linker error of type
path/to/ld[.exe]:path/to/file:line: warning: memory region ... not declaredwould be falsely detected as a GCC compiler error of typepath/to/file:line:severity: message` if the compiler errors are parsed prior to the linker errors. I already regarded this in my local fix by changing the parser execution order (linker parser is now executed before the compiler parser). But I prefer to test this a little further.Are you guys fine with that or do you prefer my current solution with linker error parsing in the GCC parser and want to delete the separate linker error parser?
RolfNoot commentedon Aug 3, 2024
I like to test as well, working a lot with gcc. Is there a repo or .vsix to test it?
0xemgy commentedon Aug 4, 2024
RolfNoot I created a new branch in my forked repo, see branch
dev/0xemgy/FixGnuLdProblemsViewPrompthere, with the solution I'm confident Garrett Campbell (@gcampbell-msft) will prefer (keeping the gnu ld parser).I generated a vsix (with local changes to the version in package.json to 99.99.0):
cmake-tools-99.99.0.vsix.zip
Edit: 99.99.1
cmake-tools-99.99.1.zip
I tested it rudimentarily:
Installed the extension manually, overwriting the latest release:
Made sure my code is really in the main.js of the extension now running (see "C:\Users\my_username.vscode\extensions\ms-vscode.cmake-tools-99.99.0\dist\main.js":
Tested it with just one warning (will test it extensively in the following weeks):
Undefined reference is detected successfully.
I also updated the typescript playground code where I tested the regex stuff over the last couple of months (see here).
So at first glance looking good, but since I am not proficient at all with typescript and desktop applications in general, I might have overlooked something. Looking forward to your feedback!
gcampbell-msft commentedon Aug 5, 2024
0xemgy Thanks for all of your work! Yes, I agree that we should solve that bug and am happy for you to implement and continue testing,
0xemgy commentedon Aug 25, 2024
Garrett Campbell (@gcampbell-msft) I was able to test my changes extensively over the last 3 weeks at work. I also added a few unit tests and cleaned up the regex expressions. For my use cases it is working properly. It is commited in the PR 3950 and is ready for review.
Of course, feedback of RolfNoot would be much appreciated.
v-frankwang commentedon Aug 29, 2024
Garrett Campbell (@gcampbell-msft) The user made some changes to the PR: #3950 based on the survey and asked you to review it.
gcampbell-msft commentedon Nov 5, 2024
Fixed in #3950.
Please open new issues if errors still remain. Thanks everyone and thanks to 0xemgy for their contribution!
Yingzi1234 commentedon Feb 14, 2025
RolfNoot We're in the process of verifying this issue, but we're not sure if the issue has been fixed, can you help us determine this by looking at the information below? If it's not correct, would you be able to provide us with a reproduction project?
Repro steps：
Actual result:
Build failed but no error message occurs on Problem window
0xemgy commentedon Mar 8, 2025
v-cathyzhang (@Yingzi1234) I implemented the fix, so I hope it's ok if I just respond here.
The error message provided by RolfNoot occurs in the Problem window after the fix.
Its is /Volumes/Data/VScode/Gatewise_AddOn01/source/main.c:105: undefined reference to 'no_reference'.
The message you get in the gif has a different format:
C:/Users/v-cathyzhang/Desktop/CMAKE/main.cpp:4:(.text+0xe): undefined reference to 'someFunction()'.
The difference is marked in bold. After the line number, you additionally get section and offset of the line.
This format is currently not supported, so the message does not get parsed.
Running your example zip, I get the message format without the section, which is correctly parsed:
Since you are using mingw version 14.2.0, and I use 13.1.0, I assume the output format might have changed.
Support for such formats could easily be added to the error parser if desired.
0xemgy commentedon Mar 9, 2025
Garrett Campbell (@gcampbell-msft), while looking into the issue v-cathyzhang (@Yingzi1234) mentioned, I ran into a couple of other things:
I've got 2, 3, and 4 sorted in #4341.
If we're going to fix 1, I'd probably need some settings to get those output formats with the extra section info. Otherwise, I could just assume the format seen in the GIF.
Hope that works for now. How do you want to proceed?