A new Visual Studio version will soon be available that deprecates the
old syntax for gsl::suppress. Customers will now get a C4875 diagnostic
on suppressions that look like `gsl::suppress(x)` urging them to use
`gsl::suppress("x")` instead.
This change updates the `GSL_SUPPRESS` macro to preprocess
GSL_SUPPRESS(x) to gsl::suppress("x") on clang and new versions of MSVC.
- reintroduce documentation internal links
- remove `gsl::` prefix in table so it is the same as in the other tables
- fix documentation for span::element_type
Co-authored-by: Werner Henze <w.henze@avm.de>
* deprecated features adopted into C++
1) Mark the following GSL features as deprecated:
- gsl::unique_ptr (always)
- gsl::shared_ptr (always)
- gsl::byte (since c++17)
- gsl::joining_thread (never implemented)
2) Refactor existing deprecations to use the new GSL_DEPRECATED(msg) macro.
3) Create a section in the README for deprecated features in the
standard.
* do not deprecate gsl::to_integer because we never claim to implement it.
* do not use gsl::byte if it is deprecated
move pipeline testing from AzDO to GitHub Actions.
* update clang versions to 13-15
* update gcc versions to 10-12
* update xcode versions to 14.3.1 and 15.4
* test against C++23 (where supported)
- Add anchor for `finally` in `headers.md` so that the link in `README.md` can work
- In `README.md` add code formatting for the character types of the `zstring` and `string_span` types
- In `README.md` change code formatting to links for GSL types
- Vertical alignment
Turns out supporting GSL.natvis perfectly is quite difficult.
There is no universal way to consume .natvis files that would satisfy everyone.
I thought the solution was to use the /NATVIS linker option. But it turns out that actually embeds information into the PDB. So I'm not sure how to properly support the Ninja generator...
That's not even accounting for the fact target_link_options doesn't play nicely with /NATVIS
When you just add the file via target_sources the visual studio solution will just pick it up and recognize it without adding it to the PDB file. Which won't affect the binary and is what most devs want.
This all comes down to the fact that /NATVIS files have native integration with visual studio that makes it difficult to use with non-visual studio solutions. /NATVIS almost works but embeds itself into the PDB which not everyone wants, and not everyone generates PDBs either.
Docs for natvis files and /NATVIS
- https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022
- https://learn.microsoft.com/en-us/cpp/build/reference/natvis-add-natvis-to-pdb?view=msvc-170
So my current solution is to just simplify the existing CMake code, and install the natvis so the user can decide.
closes#1084
This avoids propagating -std=c++14 as a compile option
Currently if you use less than CMake 3.8 and you install the project
`-std=c++14` gets added to the INTERFACE_COMPILE_OPTIONS. This forces
users to use C++ 14 or remove the property from the imported target.
The solution is to raise the minimum and use `cxx_std_14`
- Move all install logic inside gsl_install.cmake
- This makes reading the logic easier, and avoids the enable language
issue with `GNUInstallDirs` by having it included after the project
call
- Have all functions inside gsl_functions.cmake
- Use CMake idiom PROJECT_IS_TOP_LEVEL
- Update README.md
* Update pipeline build tag
The build status was still looking for a "master" branch, updated it to point to "main"
* Update ios.yml
* Update android.yml
* Update azure-pipelines.yml
* Update CONTRIBUTING.md
Carson Radtke
Werner HenzeandWerner Henze
Carson Radtke
Brian Kroth
Bruce Mitchener
Dmitry Kobets
jpr42
Eli Boyarski
Jordan Maples [MSFT]
hdf89shfdfsandJuan Ramos
Jordan Maples
Esteban Gehring
Krystian Kuzniarek
Bas Hendri
Alexander Karzhenkov
Roelf-Jilling
Hannes Steffenhagen
cbuchart
NancyLi1013