On Sat, Sep 14, 2024 at 9:42 AM René Ferdinand Rivera Morell via SG15 <
sg15_at_[hidden]> wrote:

> Do we have minutes for the last telecon?
>

Here's the raw notes, I'll add them to the wiki in a bit:

P3358R0 - SARIF for Structured Diagnostics

MS - Michael Spencer
SB - Sy Brand
DM - David Malcolm
DE - Daniela Engert
RM - Rene Morell
RR - Ran Regev
BB - Ben Boeckel
OA - Olga Arkhipova
GDR
BR - Bret Brown

SB: <presenting>

RM: Is JSON RPC part of any standards org?
SB: It's its own group

OA: <explains how MSVC uses JSON-RPC with SARIF>

SB: <presenting>

BR: Bloomberg is interested in SARIF adoption. Asking for support from
CMake.
    Interested in split output in both SARIF and normal.
SB: Agreed. We (MSVC) does this.

RM: Speaking of CMake, considering adding to build2. How do you distinguish
    between buildsystem errors and compiler errors?

OA: It would be nice if any tool related to build would be able to
communicate
    SARIF output from itself through some communication channel, usually a
pipe.
    Current convention is stderr, which is a pipe effectively. So it would
be
    nice if we have another way to chain stuff. Currently there is no
standard
    thing for SARIF propogation.

DM: I have an implementation in GCC where rather than an output pipe it uses
    unix domain sockets rather than stderr. There are two aspects to this
    proposal: let's use SARIF, and there's a specific proposal for extending
    SARIF to support higherarchical diagnostics (notes). 3rd part is RPC.

BR: Another usecase. Bloomberg interested in using this to combine
diagnostics
    in a more useful way such as handling -Werror in the build system rather
    than the compiler. Want to use it for more context in broader tooling.

DM: Also useful for optimization remarks.

GDR: Question for BR. Do I understand that you want to get both JSON RPC and
     standard output?
BR: Wants both normal diags and SARIF. Humans expect to see the normal
compiler
    output.
GDR: We have tradiationally used stderr and stdout for communicating
     diagnostics. As we've wanted more structure we've realized these
channels
     are not great.
BR: As tools catch up that alone would be useful, but for now we would need
    both.
OA: It has to be the responsitivility of the proess that launches the tool
    requesting SARIF ouptut. Because you cannot expect the compiler to
output
    its own formst just text which they do this currently because we support
    this currently. We create two pipes. One is text one is SARIF. Because
the
    IDE has process both we can't tell if a diag is in both, so we currently
    require the SARIF output ot have everything.
GDR: My concern is about wanting a 1:1 correspondense between formats.
SB: Yeah, SARIF will have more.

<continued clarification of the above points>

OA: This is really useful for build systems.

The EcosystemIS should recommend that tools support SARIF output, provide
standard options and semantics for tools that do support SARIF, and
communication of SARIF between tools.
| SF | F | N | A | SA |
| 7 | 2 | 0 | 0 | 0 |




P3335R0 - Structured Core Options

MS - Michael Spencer
SB - Sy Brand
DM - David Malcolm
DE - Daniela Engert
RM - Rene Ferdinand Rivera Morell
RR - Ran Regev
OA - Olga Arkhipova
GDR
BR - Bret Brown

RM: <presenting>

5.1 File References
OA: Can't use file paths as keys because some josn libraries don't support
not
    having pre-known keys.
<discussion around JSON string not being able to repsent all paths>
GDR: Some files exist in memory, not on disk.
OA: When talking about files these are values of switches?
RM: Yes
<purpose of this is for stuff like -x that applies to a set of files>
RM: Will adjust to have known keys.

RM: <presenting>

MS: This seems very implicit for what actions are happening, can we make
this
    explicit?
RM: Have an example of separate steps. Want to keep property of list of
sources.
OA: Do you think students will be using this?
RM: I would hope so.
MS: Similar to TypeScript.
GDR: Beginners using tools to generate this is reasonable.
RM: I think this is useful to books/tutorials for portability.
BR: One of my concerns is we don't want to overdesign. Start with the simple
    examples and worry about more sophisticated later.

OA: We map properties from MSVS to cl.exe and clang.
MS: We do a similar thing for Xcode.

OA: I just noticed that having a different value object in the json also
would
    cause a headache in some libraries. Also don't like different types.
<disccoussion around json libraries, jqery, variant types. possibly
difficult>
<start with simple json, if it's annoying then revisit>

<language would specificy just c and c++, others are impl defined>

MS: I don't like the safe optimization level.
GDR: <agrees>
BR: We should be really minimal about optimziation to start with. Maybe
just on
    and off.
GDR: If we trim this list down to off, debug, space. I think that would be a
     good starting point.
RM: If we have space we would need speed.

<sg16 is dealing with file name encoding>

MS: We'll need another telecon, RM is there anything else you need from this
    meeting?
RM: I'm good for now.

DM: Were you hoping for compiler to be able to emit this? ex. for
translation.
RM: Not expecting that.
BR: Not required, but would be interesting.

OA: We talked about being able to output its capabilities. Include section
for
    mapping? Documentation would work too.
RM: For some previous proposal I wrote a tool that did this kind of thing.
Would
    update for this.

No poll, previously polled this direction. Will meet again to go over the
rest
of the options.