[clang] [NFC][clang] Quote literal builtin attribute markers in Builtins.def docs (PR #160080)

[Radovan Božić via cfe-commits]

bozicrHT wrote:

> > > > > > But I'm not sure what we could use reasonably.
> > > > > 
> > > > > 
> > > > > We could replace it w/ e.g. `*` and add a note along the lines of ‘where `*` is any integer/index/whatever it’s actually supposed to be’
> > > > 
> > > > 
> > > > Asterisk seems pretty overloaded here... maybe the same except with `{num}` or something like that?
> > > 
> > > 
> > > What about using two letters, e.g., `"nn"`, to mark `nonnull`?
> > 
> > 
> > I experimented with using `"nn"` as the marker for builtin nonnull, but that caused 137 test failures (in SemaHLSL, SemaSPIRV, CodeGenSPIRV, CodeGenHLSL, etc.). Using `"{null}"` reduced it to 3 failing tests:
> > ```
> > Clang :: CodeGen/AArch64/strictfp-builtins.c
> > Clang :: CodeGen/X86/strictfp_builtins.c
> > Clang :: CodeGen/strictfp_builtins.c
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > The most stable option so far is **`"NN"`**, where all tests pass.
> 
> Ah, I was not suggesting we switch the `N` away from null, I'm not sure it is a particularly good idea to have ONE be 2 characters, particularly with how it is parsed. I am afraid that above, all you did is test the thoroughness of our testing :)
> 
> I was suggesting the `{num}` or whatever for the cases where the documentation is currently using `N` to mean `some random number`.

Ahh sorry for misunderstanding. :)
Yes, I was just testing how the existing tests reacted to changing the marker, since my custom tests for this feature already passed. Thanks for clarifying. I can add something like this:

```
//  C<{num},M_0,...,M_k> -> callback behavior: argument {num} is called with
//                          argument M_0, ..., M_k as payload
//  s:{num}: -> this is a scanf-like function whose {num}th argument is the
//              format string
```

https://github.com/llvm/llvm-project/pull/160080