GCC linker errors not showing up in Problems window

[RolfNoot]

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

[bobbrow]

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]

Thanks for the quick reply. Where (in code?) can I find this regex? I might change it according my needs.

[bobbrow]

It is here:

vscode-cmake-tools/src/diagnostics/gcc.ts

Line 9 in a00c339

export const REGEX = /^(.*):(\d+):(\d+):\s+(?:fatal )?(\w*)(?:\sfatale)?\s?:\s+(.*)/;

[RolfNoot]

Changing the regex doesn't affect the output. I changed the one in vscode-cmake-tools/src/diagnostics/msvc.ts which seems to affect the output.

How can I select the problemMatcher when starting build programmatically (not using Tasks) vscode.commands.executeCommand('cmake.build')?

[bobbrow]

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.

[evakili]

This issue also exists in MSVC builds. MSVC link errors are not matched by the problem matcher.

[denis-shienkov]

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]

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.

"problemMatcher": [
        {
            "base": "$gcc",
            "fileLocation": ["relative", "${workspaceFolder}/build" ]
        },
        {
            "owner": "linker0",
            "severity": "error",
            "fileLocation" : "absolute",
            "pattern": {
            "regexp": "((error): ld returned (-?\\d+) exit status)",
            "message": 1,
            "file" : 2
            }
        },
        {
            "owner": "linker1",
            "severity": "error",
            "fileLocation" : "absolute",
            "pattern": {
            "regexp": "(\\S*\\..{0,2}):(\\d*):\\s(undefined reference to `\\S*')",
            "file": 1,
            "line": 2,
            "message": 3
            }
        },
        {
            "owner": "linker2",
            "severity": "error",
            "fileLocation" : "absolute",
            "pattern": {
            "regexp": "((.*\\..{0,2}):(\\d+): (multiple definition of .+);.+:(.*\\..{0,2}):(\\d+): first defined here)",
            "message": 4,
            "file": 5,
            "line": 3
            }
        },
        {
            "owner": "linker3",
            "severity": "error",
            "fileLocation" : "absolute",
            "pattern": {
            "regexp": "((cannot open linker script file (.+.ld): No such file or directory))",
            "message": 1,
            "file": 3
            }
        },
        {
            "owner": "linker4",
            "severity": "error",
            "fileLocation" : "absolute",
            "pattern": {
            "regexp": "((region `\\S+' overflowed by \\d+ bytes))",
            "message": 1
            }
        }

[denis-shienkov]

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..

I even created an issue about that:

• Extend the diagnostics API to allow the diagnostic collections without of a URIs vscode-cpptools#6643
• Extend the diagnostics API to allow the diagnostic collections without of a URIs vscode#112145

but all was unsucessfull.

[RolfNoot]

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]

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).