-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GCC linker errors not showing up in Problems window #2864
Comments
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. |
Thanks for the quick reply. Where (in code?) can I find this regex? I might change it according my needs. |
It is here:
|
Changing the regex doesn't affect the output. I changed the one in How can I select the problemMatcher when starting build programmatically (not using Tasks) |
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 |
This issue also exists in MSVC builds. MSVC link errors are not matched by the problem matcher. |
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. This should be implemented in the extension IMHO.
|
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 I even created an issue about that:
but all was unsucessfull. |
Hmm.. Is it possible at all to set a null path? Because the vscode.DiagnosticCollection expects the the method |
I am assuming it's a 'null' path, an empty string or just a '/' which is a valid Uri. The screenshot above shows that it's possible at least. Not sure how the problemmatcher internally works and I am not typescript expert either. |
Maybe the regex fails because there is a Following regex will match above line: EDIT: running |
I tinkered with the gcc parser because showing the linker errors in the Problems panel is really helpful. What I basically did is I added some more regex cases and modified the handling of the additional matches. If there is no column, 1 is set as column, if there is no severity, error is set as severity, etc. Here are the Typescript Regex trial and errors is used, if anyone wants to add some more special cases. Here is the modified gcc parser:
To use this parser instead of the original one, you have to modify the main.js in your vscode-cmake-tools, which is located here: The parser code starts at line L52429 and ends at line L52516. Just replace the code form start line to end line, perform Reload Window if vscode is opened, and the modified version should be running without further ado. The first undefined reference error is a linker error without a column and without a severity. I is not parsed without the modifications. This has not been thoroughly tested. It is a work in progress. It will probalby need some refinements, it might even detect some false positives, or not work for Linux developers etc. I probably did not handle the Hope this helps somebody. Cheers Edit 1: Since I expect more additions for linker warnings with a weird format resulting in the need for more regex patterns, I made the code a little more generic so that only the pattern and the match types need to be added and no logic must be touched anymore. Edit 2: Edit 3: |
@0xemgy Thanks for the investigation and comments. This seems like a GREAT opportunity for you to improve the extension for everyone by making an Open Source Contribution! Is this something you feel confident would work for everyone and would be willing to PR? |
I agree that this seems like a great opportunity and I would be willing to contribute. But right now I don't feel confident that this would work for everyone. Because:
Definitely no insurmountable problem there, but quite a few aspects to consider. So I'd say I will test this further, edit my original comment if I have added/fixed something, and do some research for Linux, the template error case, and further common linker errors. And then I will attempt to contribute, which would be my first contribution ever, so I would need to see how that works too. Depending on my spare time this might take a few weeks or months. Does that sound like a plan or do you have a better suggestion? |
@0xemgy Thank you for all of that context. That sounds like a great plan! If we end up deciding to prioritize this issue such that we also start investigating and working on it, we will make sure to follow up here so that we can sync and make sure that no work is duplicated. Thank you. |
@0xemgy Thank you so much for your response and your contribution to the community! If you make any progress, we'll follow up on this here as well after you update the comment or add a new one. |
@gcampbell-msft @v-frankwang Regarding my previous concerns:
So now I'm confident in my solution and I am willing to PR. I already created a branch locally, modified the gcc.ts and was able to build it, test the parsing with my local software project, and ran the unit tests without an error. But I am not allowed to push: |
@gcampbell-msft The user has created a branch of his own with his changes, but cannot push to the corresponding branch of microsoft/vscode-cmake-tools, can you give the user some advice? |
@v-frankwang @0xemgy Thanks for all of your work and your updates! Let's get it such that you can contribute. The reason that you are getting the permission errors is because in order to create a PR, you should first create a fork of the cmake-tools repository, and then you can create a PR from that into this repository. Does that make sense? Please let me know if you need/want any help with this. |
@gcampbell-msft @v-frankwang I think I got it: Forked the repo, created a PR, agreed to the CLA: #3950 |
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 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. 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. 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? |
I like to test as well, working a lot with gcc. Is there a repo or .vsix to test it? |
@RolfNoot I created a new branch in my forked repo, see branch I generated a vsix (with local changes to the version in package.json to 99.99.0): I tested it rudimentarily:
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! |
@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, |
@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. |
@gcampbell-msft The user made some changes to the PR: #3950 based on the survey and asked you to review it. |
Brief Issue Summary
I am not sure whether this is an issue or expected behavior. Compiler errors are shown correctly.
CMake Tools Diagnostics
No response
Debug Log
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: