Used json::OStream directly to omit null and default values.
Added error handling and the error code/message printout in JSON.

Thanks for the comments, James!
I will address them later.
With all these issues this draft is still provide quite good idea of the level of the changes if we will decide JSON.
As you mentioned, I’d like us to choose before making further changes.

Ping

Just one more ping!

This patch is a continuation of the discussion https://reviews.llvm.org/D96289

Here is the patch for supporting JSON - https://reviews.llvm.org/D96883
Now we can look at the changes side by side and decide which one is the way to go.

Ping! Please, don't pass by this patch. I need your competent evaluation to load it!

In D96289#2560919, @MaskRay wrote:

The line based output can be straightforwardly parsed

And this is fine. I do not see how this patch could prevent your users from parsing the line based output. It is quite the opposite, they are even better protected, as any change in YAML output style would not change what they depend on.

I have updated the patch. It

• addresses the review comments,
• adds more tests for YAML output style similar to the existing tests we have for other output styles. In particular output-style-yaml-data.test is based on untag-addresses.test, output-style-yaml-frame.test is based on frame-types.s.
• updates llvm-symbolizer documentation.

Thanks for the comments, James! I’ll post the updated patch shortly.

Hi, community. I kindly ask you to review this patch.

One more ping. Please, pay attention to this patch.

Please, look at my solution. Is it worth to be accepted?

Just a ping.

@Quuxplusone
Thank you for your comments. I updated the patch according to your suggestions.
Does anyone else from the review list want to waste some time to look at this patch? I would appreciate this.

Please, somebody look at this patch.

One more ping!

Hi, community. I kindly ask you to review this patch.

Updated. Disabled function parameters access checking in function templates.
Hi, @broadwaylamb, @rsmith, @saar.raz, @doug.gregor, @mibintc, @hokein. Could you please look at this patch?

Simplify the patch.
@Quuxplusone,
Actually you've pushed me to some thinking of what more syntactic cases it could be. And I came to that we can get rid of this hack and simplify the patch pretty much. Hope, this fix will be more admissible.

Added test cases for explicit instantiations.

@Quuxplusone,
In particular, I'm very interested to know if P0692 is intended to have any effect on the legality of https://godbolt.org/z/fqfo8q

I've checked your particular case. It hasn't been affected by this patch. It works as before. I also added it to func.spec.cpp.

In D92024#2431452, @Quuxplusone wrote:

The subject line says "access checking on specializations and instantiations," but I don't see any tests for explicit instantiations here — just specializations. In particular, I'm very interested to know if P0692 is intended to have any effect on the legality of https://godbolt.org/z/fqfo8q

Thank you for your important suggestion! I'll add test cases for explicit instantiations.

It would also be good to document which of the two proposed wordings from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0692r1.html is actually being adopted in this patch.

AFAIK there are four options in the paper. This patch covers option *A*. I'll mention this in the summary.
Both wordings relate to option A only, thus both wordings have been adopted.

Fixed typos. Made minor changes in test cases.

Improved solution. Added more tests.

Disable compiler-rt crt tests for cross ARM builders since the tests are broken.

Since we use this utility in multiple projects now, it is better to have it outside the libc++ project, so we would not introduce unneeded inter-project dependencies just because of shared tools.

Changed the parameter --test-executable to --exec-pattern;
Used regex instead of fnmatch;
Fixed bugs that appeared in case of complicated command line.
Note I used the following command line for tests:
python remote-exec.py --host user@host --execdir llvm-project/build/runtimes/runtimes-bins/libcxx/test/std/input.output/iostream.objects/narrow.stream.objects/Output/cin.sh.cpp.dir --codesign_identity "" --env "" -- echo "123" "|" llvm-project/build/runtimes/runtimes-bins/libcxx/test/std/input.output/iostream.objects/narrow.stream.objects/Output/cin.sh.cpp.dir/t.tmp.exe ">" t.tmp.out "&&" grep -e "The number is 123!" t.tmp.out

I have created a review https://reviews.llvm.org/D89349 for llvm/utils/remote-exec.py as discussed here.

Committed as 938392e5a2575dcf6a04132f172b091a6a7e05fe.