[clangd] Support square bracket escaping in Annotations

[fefaleksey]

The Annotations class is not supporting C++ attributes [[...]] because the attributes are parsed as a selection. The proposed improvement allows [, ] characters to be escaped (example: \[\[nodiscard\]\]), allowing attributes to be used.

[fefaleksey]

@sam-mccall @kadircet Hello! Could you please review this PR?

[sam-mccall]

The usual workaround for this is to use the digraph <: in place of [. Does this work for your case?

I'd prefer not to add a second escaping mechanism if the existing one does work, maybe we should document it though.

[fefaleksey]

The usual workaround for this is to use the digraph <: in place of [. Does this work for your case?

I'd prefer not to add a second escaping mechanism if the existing one does work, maybe we should document it though.

Yes, this works well, but in this case we will not be able to test the [[ ... ]] attributes. This may be important, for example, for testing a tweak for moving functions (with its attributes). What do you think about it?

[fefaleksey]

@sam-mccall friendly reminder)

[sam-mccall]

Yes, this works well, but in this case we will not be able to test the [[ ... ]] attributes.

Can you explain a bit further?
These can be spelled [<: ... :>] or <:<: ... :>:> in the code, which should have the same effect.

Code that moves attributes around would ideally not be too sensitive to the char-by-char spelling, as these are often hidden behind macros etc.

Is the concern that the code being tested might work with digraphs but not with literal [ characters?
(It is unfortunate if a test isn't realistic, but this doesn't seem terribly likely)

[fefaleksey]

Yes, this works well, but in this case we will not be able to test the [[ ... ]] attributes.

Can you explain a bit further? These can be spelled [<: ... :>] or <:<: ... :>:> in the code, which should have the same effect.

Code that moves attributes around would ideally not be too sensitive to the char-by-char spelling, as these are often hidden behind macros etc.

Is the concern that the code being tested might work with digraphs but not with literal [ characters? (It is unfortunate if a test isn't realistic, but this doesn't seem terribly likely)

Actually yes, I had concern that the code being tested might work with digraphs but not with literal [ characters, because <: has 2 symbols, but [ is only one symbol. But maybe you are right and the probability is really low.
If you think that this is not necessary, then I think we can close the PR.