Re: [PATCH] Add gnu::diagnose_as attribute

[Matthias Kretz <m.kretz@gsi.de>]

On Tuesday, 1 June 2021 21:12:18 CEST Jason Merrill wrote:
> On 5/28/21 3:42 AM, Matthias Kretz wrote:
> > On Friday, 28 May 2021 05:05:52 CEST Jason Merrill wrote:
> >> I'd think you could get the same effect from a hypothetical
> >> 
> >> namespace [[gnu::diagnose_as]] stdx = std::experimental;
> >> 
> >> though we'll need to add support for attributes on namespace aliases to
> >> the grammar.
> > 
> > Right, but then two of my design goals can't be met:
> > 
> > 1. Diagnostics have an improved signal-to-noise ratio out of the box.
> > 
> > 2. We can use replacement names that are not valid identifiers.
> 
> This is the basic disconnect: I think that these goals are
> contradictory, and that replacement names that are not valid identifiers
> will just confuse users that don't know about them.

With signal-to-noise ratio I meant the ratio (averaged over all GCC users - so 
yes, we can't give actual numbers for these):

  #characters one needs to read to understand / #total diagnostic characters.

Or more specifically

  1 - #characters that are distracting from understanding the issue / #total 
diagnostic characters.

Consider that for the stdx::simd case I regularly hit the problem that vim's 
QuickFix truncates at 4095 characters and the message basically just got 
started (i.e. it's sometimes impossible to use vim's QuickFix to understand 
errors involving stdx::simd). There's *a lot* of noise that must be removed 
*per default*.

WRT "invalid identifiers", there are two types:
(1) string of characters that is not a valid C++ identifier
(2) valid C++ identifier, but not defined for the given TU

(2) can be confusing, I agree, but doesn't have to be. (1) provides a stronger 
hint that something is either abbreviated or intentionally hidden from the 
user.

If I write `std::experimental::simd<float>` in my code and get a diagnostic 
that says 'stdₓ::simd<float, simd_abi::[SSE]>' then it's relatively easy to 
make the connection what happened here: 'stdₓ' clearly must mean something 
else than a literal 'stdₓ' in my code. The user knows there's no `std::simd' 
so it must be `std::experimental::simd`. (Note that once 
std::experimental::simd goes into the IS, I would be the first to propose a 
change for 'stdₓ::simd' back to 'std::experimental::simd'.)

> If a user sees stdx::foo in a diagnostic and then tries to refer to
> stdx::foo and gets an error, the diagnostic is not more helpful than one
> that uses the fully qualified name.

Hmm, if GCC prints an actual suggestion like "write 'stdₓ::foo' here" then 
yes, I agree. That should not make use of diagnose_as.

> Jonathan, David, any thoughts on this issue?
>
> > I can imagine using it to make _Internal __names more readable while at
> > the
> > same time discouraging users to utter them in their own code. Sorry for
> > the
> > bad code obfuscation example above.
> > 
> > An example for consideration from stdx::simd:
> >    namespace std {
> >    namespace experimental {
> >    namespace parallelism_v2 [[gnu::diagnose_as("stdx")]] {
> >    namespace simd_abi [[gnu::diagnose_as("simd_abi")]] {
> >    
> >      template <int _Bytes>
> >      
> >        struct _VecBuiltin;
> >      
> >      template <int _Bytes>
> >      
> >        struct _VecBltnBtmsk;
> >    
> >    #if x86
> >    
> >      using __ignore_me_0 [[gnu::diagnose_as("[SSE]")]] = _VecBuiltin<16>;
> >      using __ignore_me_1 [[gnu::diagnose_as("[AVX]")]] = _VecBuiltin<32>;
> >      using __ignore_me_2 [[gnu::diagnose_as("[AVX512]")]] =
> >      _VecBltnBtmsk<64>;
> >    
> >    #endif
> >    }}}}
> > 
> > Then diagnostics would print 'stdx::simd<float, simd_abi::[AVX512]>'
> > instead of 'stdx::simd<float, simd_abi::_VecBltnBtmsk<64>>'. (Users utter
> > the type by saying e.g. 'stdx::native_simd<float>', while compiling with
> > AVX512 flags.)
>
> Wouldn't it be better to print stdx::native_simd<float> if that's how
> the users write the type?

No. For example, I might expect that native_simd maps to AVX-512 vectors but 
forgot the relevant -m flag(s). If the diagnostics show 'simd<float, 
simd_abi::[SSE]>' I have a good chance of catching that issue.
And the other way around: If I wrote `stdx::simd<float>` and it happens to be 
the same type as the native_simd typedef, it would show the latter in 
diagnostics. Similar issue with asking for a simd ABI with 
`simd_abi::deduce_t<float, 16>`: I typically don't want to know whether that's 
also native_simd<float> but rather what exact simd_abi I got. And no, as a 
user I don't typically care about the libstdc++ implementation details but 
what those details mean.

-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research               https://gsi.de
 std::experimental::simd              https://github.com/VcDevel/std-simd
──────────────────────────────────────────────────────────────────────────