Support uriBaseId

[lcartey]

SARIF supports the concept of URIs which are relative to some uriBaseId. The spec includes this example:

"fileLocation": {
  "uri": "drivers/video/hidef/driver.c",
  "uriBaseId": "%srcroot%"
}

Here, uri is a relative reference to a given base - in this case %srcroot%. This makes it easier to provide portable SARIF files - typically, the uri property is given as a relative reference to the root directory of the project, removing the machine specific part. In fact, the spec states that if the uri is relative, a uriBaseId should also be provided.

In order to resolve the relative URI reference to create an absolute URI, the uriBaseId needs to be resolved. From the spec:

The uriBaseId property can be any string; it does not need to have any particular syntax or follow any particular naming convention. In particular, it does not need to designate a machine environment variable or similar value, although it might. The SARIF producer and any SARIF consumers need to agree on the meanings of any values for the uriBaseId property that appear in the log file.

For example, on opening a SARIF file including URI base ids, the Visual Studio SARIF extension asks for the location of the first file in the log, and then uses this to determine the value of the variable in the uriBaseId property, which is used when resolving further relative uri references to the same uriBaseId.

The VS Code extension currently ignores the uriBaseId property completely. When provided with a log file which uses such relative URI references, the remapping is actually somewhat unintuitive - as with the VS extension, it asks to remap the file. However, unlike the VS extension, it appears to treat the first element in the relative URI as the "base".

For example, in the example above if we gave C:\src\drivers\video\hidef\driver.c as the full path, the VS Code extension appears to store the mapping drivers/ -> c:\src\drivers. Further entries in the drivers directory are automatically mapped, but files in a different directory cause an additional dialog to be popped up, once for each top-level directory, requesting the location of the first file in that directory. This is particularly confusing in combination with #58, as the file dialogs don't mention the file that is being mapped.

[rscrivens]

thanks for the feedback, we have a task #25 that's on the backlog for adding this support. Looking to adding it in for the next milestone.

[michaelcfanning]

@rscrivens, we promised this last milestone, any updates?

[michaelcfanning]

Oops, I see my confusion. This is a duplicate of #25 and that item is clearly marked for current release process. Sorry for the noise, closing this item.