What can arguments to placeholders contain? (§3.11.11 and §3.11.15)

[davidmalcolm]

Within a §3.11 message object, the arguments array is shared for use by both text and markdown (if any), in that (quoting §3.11.5 Messages with placeholders):
" The plain text and formatted message strings MAY contain different numbers of placeholders.

· A given placeholder index SHALL have the same meaning in the plain text and formatted message strings (so they can be replaced with the same element of the arguments array)."

I'm hoping for clarification on the following points:

Can an argument contain any formatting, such as embedded links?

§3.11.5 Messages with placeholders has: "A given placeholder index SHALL have the same meaning in the plain text and formatted message strings (so they can be replaced with the same element of the arguments array)."
which to me suggests that every argument of the arguments array must be a plain string: no embedded links, and (probably) no markdown markup.

Should a consumer perform markdown processing before or after argument substitution?

Consider if an argument string contained markdown markup. According to
§3.11.5 Messages with placeholders: "When a SARIF consumer displays the message, it SHALL replace every occurrence of the placeholder {n} with the string value at index n in the arguments array." Does this happen before or after handing off the string to markdown rendering? Should arguments be "plain" strings? (in which case this ordering is moot)

Or should some kind of markdown escaping happen on arguments during substitution?

Consider e.g. this message:

{
  "text", "expressions:\n {0}\n {1}",
  "markdown": "expressions:\n {0}\n {1}",
  "arguments": ["* p",  "* q"]
}

A substitution of text leads to "expressions:\n * p\n *q" which would be rendered as something like:

expressions:
* p
* q

but naively subtituting, the markdown would become like:

expressions:

• p
• q

and thus the dereference operators in the text have become bullet-point markup.

[davidmalcolm]

Here's another example, which arose in my unit-testing for GCC's sarif generation.

I have a test that tries to emit the message
Prohibited term used in para[0]\spans[2]
where the para[0]\spans[2] is to have a URL, but the URL is supplied as a placeholder within GCC's formatted printing handler.

Naively, this could become:

"text":"Prohibited term used in [para[0]\spans[2]]({0})",
"arguments": "PLACEHOLDER-URL"

where the URL part of the embedded link is expressed via a placeholder.

Is this legal SARIF? (such a usage seems questionable to me, FWIW).

A more diabolical example:

"text":"Prohibited term used in [para[0]\{0}",
"markdown":"Prohibited term used in [para[0]\{0}",
"arguments": "spans[2]](PLACEHOLDER-URL)"

where the embedded link syntax is only seen after placeholder substitution (and the text for the anchor is split between the text and arguments[0]

Is this legal SARIF? (I suspect not; presumably the schema can't express the substitution of the placeholder)

[davidmalcolm]

Another ambiguity that arose in my testing.

3.11.5 Messages with placeholders has:
"Within both plain text and formatted message strings, the characters “{” and “}” SHALL be represented by the character sequences “{{” and “}}” respectively."

Consider:

"text": "open brace: {0} close brace: {1}",

where I want the arguments to be an open brace and a close brace.

Should this be:
arguments": ["{", "}"]
or
arguments": ["{{", "}}"]

I'm assuming that producers don't have to spell braces as {{ and }} in arguments, just within text and markdown. But the other interpretation is possible; I think.

[davidmalcolm]

...and a concrete example that arose working on an implementation of #662; my code generated this SARIF:

"message": {"text": "invalid operands to binary {0} (have {1} and {2})",
            "arguments": ["+",
                          "‘S’ {aka ‘struct s’}",
                          "‘T’ {aka ‘struct t’}"]},

for this textual output:

error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t'}

Note the braces in the arguments: my implementation isn't escaping them; should it?