* clang-format improvements
- Add a clang-format linter check to the PR pipeline
- Apply clang-format to files where the linter initially failed
- Remove `CommentPragmas` from `.clang-format`
- Remove all `// clang-format off` and `// NO-FORMAT` as they are not needed
- Remove a commented out `GSL_SUPPRESS`
* clang-format 20
* pipeline fail
* Update .github/workflows/clang-format.yml
Co-authored-by: Carson Radtke <nosrac925@gmail.com>
* output used clang-format version
* installed version is 18 which replaces "GSL_SUPPRESS(bounds.1)" with "GSL_SUPPRESS(bounds .1)"
* only include/gsl, not include
to prevent formatting of include/CMakeLists.txt
* apply clang-format[-20]
In a VS2026 developer command prompt I ran `clang-format -i include\gsl\* --assume-filename x.cpp`. This was necessary because VS GUI does not format files without an extension :(. Please note that `--assume-filename` is necessary here, otherwise the files will not be formatted. Surprisingly the behaviour for the formatter differs from the behaviour of `lang-format(-20) --dry-run --Werror include/gsl/*` where clang-format recognizes that the files is C++.
* change "#if 0" back to original version with comments only
* formatting scripts for windows and linux
for linux with linter (shfmt and shellcheck)
* add WhitespaceSensitiveMacros: [GSL_SUPPRESS]
* provide path for clang-format (Windows)
Currently not clear to me:
On my personal computer at home, when I start "Developer Command Prompt for VS18", I can run `clang-format` without providing the path.
On my managed (domain) company computer, when I start "Developer Command Prompt for VS18", I can NOT run `clang-format` without providing the path. I need to call `"%VCINSTALLDIR%Tools\Llvm\bin\clang-format"`.
I have no idea what the difference is. At least the version `"%VCINSTALLDIR%Tools\Llvm\bin\clang-format"` works on both computers, so I add the path.
---------
Co-authored-by: Werner Henze <w.henze@avm.de>
Co-authored-by: Carson Radtke <nosrac925@gmail.com>
Co-authored-by: Werner Henze <werner.henze+gitcommits@posteo.de>
Without this change, the guideline
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c89-make-a-hash-noexcept
would be violated.
The test fails before the changes here:
```
tests/pointers_tests.cpp:102:23: error: static assertion failed due to requirement 'noexcept(std::hash<gsl::not_null<std::shared_ptr<int>>>{}(std::declval()))': gsl::not_null hash operator must be noexcept
102 | static_assert(noexcept(std::hash<Key>{}(std::declval<Key>())),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tests/pointers_tests.cpp:108:23: error: static assertion failed due to requirement 'noexcept(std::hash<gsl::strict_not_null<std::shared_ptr<int>>>{}(std::declval()))': gsl::strict_not_null hash operator must be noexcept
108 | static_assert(noexcept(std::hash<Key>{}(std::declval<Key>())),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
- `strict_not_null<std::unique_ptr<int>>{ std::make_unique<int>()}` failed to compile
- `strict_not_null` ctor needs to move the passed `unique_ptr`, not copy
- Copied `not_null` `TestNotNullConstructors` for `strict_not_null`
- The `noexcept` specifiers on the `strict_not_null` and `not_null` constructors were out of sync.
- Added unit test for `not_null<unique_ptr<T>>` and for `strict_not_null<unique_ptr<T>>`
- Added unit test for `gsl::swap` for two `strict_not_null`
- Added unit test for `gsl::swap` for `not_null` and `strict_not_null`
Co-authored-by: Werner Henze <w.henze@avm.de>
Werner Henze
maflcko
Carson Radtke