Paths relative to some parent directory in task with problemMatcher

[mprobst]

• VSCode Version:
  Version 1.12.2
  Commit 19222cd
  Date 2017-05-10T13:16:25.899Z
  Shell 1.6.6
  Renderer 56.0.2924.87
  Node 7.4.0

• OS Version: Linux 4.4.0-75-generic Add support for Perl5 symbol indexing #96~14.04.1-Ubuntu SMP Thu Apr 20 11:06:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I'm trying to write tasks for the bazel build system (http://bazel.build). With bazel, it's common to have very large projects, so users often open subdirectories in VSCode, instead of the project root. bazel still prints all messages relative to its workspace root though. For example, given the source tree:

my/
  BUILD
  WORKSPACE
  foo.ts
  project/
    BUILD
    bar.ts
    subdir/
      baz.ts

Users might open my/project/ in VSCode (as the workspace location). Now running bazel build with a working directory of my/project, it'll print errors such as:

foo.ts(123): error here
project/subdir/baz.ts(456): another error here

Note that paths are relative to the workspace root (my/ above, the directory containing the WORKSPACE file). problemMatcher supports paths relative to the directory opened in VSCode and absolute paths, but AFAICT not paths relative to some parent folder.

I guess this is hard to support in a configuration file format. Maybe it'd be easier if there was an API for an extension to contribute problem matchers (and tasks, for that matter)?

[dbaeumer]

@mprobst it does. The problem matcher accept for the fileLocation property and array of strings as well. Something like:

"problemMatcher": {
	"fileLocation": ["relative", ".."]
}

Let me know if this works for you. If not ping and I will reopen the issue.

[xaljox]

Seems to me that with the ".." fix you have to edit your task file every time you open from a different location.
I have similar issues here, I always open at the same location, but the project is nested as well and makefiles execute makefiles at another lower level. However, a change directory is done, this is reported with statements like:
make[1]: Leaving directory '/media/psf/Home/GitHub/bash/bash-4.4/build/builtins'
make[1]: Entering directory '/media/psf/Home/GitHub/bash/bash-4.4/build/support'
In this kind of environment which is not that uncommon, it seems kind of impossible to get the problem matcher working properly. Depending on the area you are working on you have to edit the tasks file to get a correct link to the file.

[xaljox]

To be more clear, the reported errors are always relative to the current working directory, but the current working directory changes during the build process. And to complicate things more the leaving statements pops back to the previous one, so if you parse the entering and Leaving statements, it is not stateless. You have to keep track of a stack of directories.

[dbaeumer]

@xaljox this is a know problem we have an issue for.

[dbaeumer]

See #11663