remove space in GSL_SUPPRESS

[beinhaerter]

As VS2026 wants a string literal in [[gsl::suppress(...)]] it is a difference, if you GSL_SUPPRESS(a.1) without space or GSL_SUPPRESS(a .1) with space. The version with the space does not work, so this commit removes the spaces.

[beinhaerter]

Most lines with GSL_SUPPRESS have a trailing // NO-FORMAT: attribute. I have left it here, but when we remove the NO-FORMAT, the VS formatting already fixes the f .4 to f.4.

I not only don't see a reason to write NO-FORMAT, I also think it makes things worse. I vote to remove all NO-FORMAT on GSL_SUPPRESS and revisit the necessity of CommentPragmas: '^ NO-FORMAT:' in .clang-format. If you agree, I can do that in another PR.

[carsonRadtke]

VS formatting already fixes the f .4 to f.4.

Does this happen with older toolsets? Specifically, when GSL_SUPPRESS(abc.123) expands to [[gsl::suppress(abc.123)]] instead of [[gsl::suppress("abc.123)]]?

revisit the necessity of CommentPragmas: '^ NO-FORMAT:' in .clang-format

I'm not running clang-format on every change. Seems like we are not compliant with what clang-format wants either:

PS C:\Users\carsonradtke\src\GSL\include\gsl> clang-format -i *
is a directory
is a directory
PS C:\Users\carsonradtke\src\GSL\include\gsl> git diff --stat
 include/gsl/byte     |  32 +++++++++-------
 include/gsl/gsl      |  14 +++----
 include/gsl/narrow   |  29 +++++++--------
 include/gsl/pointers | 101 ++++++++++++++++++++++++++++++---------------------
 include/gsl/span     |  17 ++++++---
 include/gsl/util     |  28 +++++++++-----
 include/gsl/zstring  |   2 +-
 7 files changed, 130 insertions(+), 93 deletions(-)
PS C:\Users\carsonradtke\src\GSL\include\gsl> 

If you agree, I can do that in another PR.

Sounds good to me. In addition to the CommentPragmas change, maybe also add a GitHub action that requires $ clang-format -i --dry-run include/gsl/* tests/*.{cpp,h} to exit successfully? This adds friction to people submitting PRs, but at least we have an agreed upon style. Your choice.

[carsonRadtke]

Does this happen with older toolsets?

I'll validate this afternoon and if all is good, I'll approve and merge.

[carsonRadtke]

Er - on older toolsets this wouldn't matter because abc.123 would be parsed the same way as abc. 123. However, I'm surprised that clang-format makes this change when the macro is expanded with the argument as a string. This type of refactor changes the meaning of the program. In the case of GSL_SUPPRESS the reactor is safe, but not in general. Anyway, merging now.

Edit: typo

[beinhaerter]

Great, #1251 is work in progress.

[carsonRadtke]

LGTM and feel free to remove the NO-FORMAT stuff in a future PR.