Vscode: Problem matcher can't support absolute and relative filenames at the same time

[Wosi]

I have a problem matcher that works on the output of the Delphi compller. Sometimes it gives relative and absolute file names at the same time. When I set "fileLocation": ["absolute"] the messages having relative paths can't be opened. When I set "fileLocation": ["relative", "${workspaceRoot}"] the messages having absolute paths can't be opened anymore.

Is it possible to define a a problem matcher that uses relative paths as long as the mentioned file exists and uses absolute paths as a fallback mode?

[dbaeumer]

The idea was to file path autodetection support. Something like:

"fileLocation": ["autoDetect"]

It would check whether a path appears to be relative or absolute (e.g. starts with / or a drive letter). Would that help in your case.

[Wosi]

That would solve my problem, yes.

[Gama11]

We need this feature for vshaxe (https://github.com/vshaxe/vshaxe) as well - the Haxe compiler reports errors with absolute paths if the error is in a haxelib somewhere outside of the current project, and relative otherwise.

[9il]

It is also required by Dlang compilers.

[Pagghiu]

I am hitting the same issue using C++ with clang. Sometimes error paths are reported as relative and sometimes are absolute.
The fileLocation could be a list of paths, with absolute and relative specification, just like a C++ include path list.

[andrewleech]

Same issue with mbed compiler, it generally just prints the filename that errors are in, it would be great if it could file the file in the browse path or let me supply a list of paths to search in.

[ncannasse]

I would like to up this one more, this is quite a show stopper as there is no real workaround once you have an absolute path, for instance on a different drive.

[dbaeumer]

Would anyone like to work on a PR for it.

[Gama11]

For now, we found a workaround for this in the Haxe extension: provide two problem matchers, one of them being listed first to have priority and having a pattern that only matches against absolute paths ((?=[a-zA-Z]:|\\/)). This seems to work nicely.

The only annoying part is that "Configure Default Build Task" copy-pastes the problem matchers of contributed tasks into tasks.json, so users who have already done that in the past will have to add the additional problem matcher manually.

[graph]

MSVC sometimes outputs paths in relative paths, and sometimes in absolute path. I would like the problem matchers to try harder to find files. If the problemMatcher is upgraded I prefer there to be no "relative" or "absolute" option and "fileLocation" to always be a path and "autoDetect" is the only option. Autodetection I can't imagine being too heavy just test if the file exists if not try as absolute, if not then try relative to project, if that fails try relative to build and if that fails then nothing much can be done. That will cover majority of the cases and will allow having it much simpler and not requiring to specify a fileLocation.

[felipecock]

I have the same issue with problem matcher, I uninstalled all extensions except Platformio.io and C/C++ (Microsoft), but the links in the problem matcher are still broken because the path is duplicated.
Unable to open 'Datalogger.ino': File not found (file:///home/felipe/Documents/PlatformIO/Projects/Bluepill_Datalogger/home/felipe/Documents/PlatformIO/Projects/Bluepill_Datalogger/src/Datalogger.ino).

I've tied to clean compile with these three settings and the wrong path managing persists :
"problemMatcher": { "base":"$platformio", "fileLocation": ["relative", "/"] // "fileLocation": ["relative", "${workspaceRoot}"] // "fileLocation": "absolute"
I hope you could fix this bug. Thanks for listening.

Related threads:
https://github.com/Microsoft/vscode-cpptools/issues/1915

[dbaeumer]

@alexr00 thanks for addressing this.

[graph]

Nice. Looking at the commit https://github.com/microsoft/vscode/commit/c5410560cf49af4fffb255b444552dcf7b74f5ce it looks like fileLocation documentation hasn't been updated "AutoDetect" though. Will this value be documented and available?

[alexr00]

We usually don't write documentation until we've release a feature. I'll add documentation around the time when autoDetect is part of a release. You can try it the insiders build soon.