* improve performance of span_iterator w/ clang
Issue: #1165
Before this PR, the range-for loop was ~3300x slower. After this PR, it
is ~1.005x slower
The clang optimizer is very good at optimizing `current != end`, so
we changed to this idiom. This moves the Expects assertion into the
constructor instead of on the hot-path which is called whenever either
operator++ or operator* is called.
Note: The codegen for the assertion is still a missed optimization,
but less worrisome as it only happens once per iterator.
Note: benchmarks on M1 Macbook Pro w/ Apple Clang 16.0.0
* Remove unused headers from gsl/pointers
forward is already declared in utility, no need to include algorithm which is relativaly heavy
hash is already declared in memory, no need to bring brand-new header system_error for hash only
* Fix: add missing header <functional> to gsl/pointers due to using less/greater
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)
Job has been failing for months and is preventing other PRs from getting
merged. This PR fixes the pipeline - it changed the following:
- runs on macos-latest-large (which is a non-arm image)
- starts the emulator under java8 (see
https://learn.microsoft.com/en-us/java/openjdk/transition-from-java-8-to-java-11)
- runs emulator with -no-audio
The above were requirements to get the pipeline running. Other changes
include the following:
- The job will auto-cancel when a newer commit is pushed to the
PR.
- The 'Wait for emulator ready' step now has a 2 minute timeout. This
is necessary because we get no indication on whether or not the
command that started the emulator suceeded. I believe there is room
for improvement here, but it is outside the scope of the PR.
Two warnings were being emitted in the MSVC+LLVM tests.
The warning `-Wunsafe-buffer-usage` is initially introduced in some capacity here https://reviews.llvm.org/D137346 pointing to documentation at https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734. The warning is a stylistic checker whose goal is to "emit a warning every time an unsafe operation is performed on a raw pointer". This type of programming model is not useful for library implementations of types such as `span`, where direct manipulation of raw pointers is inevitable, so disable the warning altogether.
There is also a false-positive warning https://github.com/llvm/llvm-project/issues/65689 that I've disabled inline.
- 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
Without this change a `gsl::not_null<class_type>` triggers these `noexcept` warnings:
```
.../gsl/include/gsl/pointers:162:50: warning: noexcept-expression evaluates to ‘false’ because of a call to ‘constexpr gsl::details::value_or_reference_return_t<T> gsl::not_null<T>::get() const [with T = class_type*; gsl::details::value_or_reference_return_t<T> = class_type* const]’ [-Wnoexcept]
162 | const not_null<U>& rhs) noexcept(noexcept(lhs.get() == rhs.get()))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../gsl/include/gsl/pointers:119:55: note: but ‘constexpr gsl::details::value_or_reference_return_t<T> gsl::not_null<T>::get() const [with T = class_type*; gsl::details::value_or_reference_return_t<T> = class_type* const]’ does not throw; perhaps it should be declared ‘noexcept’
119 | constexpr details::value_or_reference_return_t<T> get() const
| ^~~
```
Co-authored-by: Werner Henze <w.henze@avm.de>
Headers that were previously prefixed with `gsl_` were renamed to drop the `gsl_` prefix in https://github.com/microsoft/GSL/pull/946, and the original version deprecated.
The deprecation happened a long time ago, so it is now time to remove these headers entirely.
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
Using `<`,`<=`,`>`,`>=` to compare unrelated pointers gives an unspecified result according to the standard.
This PR replaces the usage of these operators in `gsl::not_null` with the STL counterparts, which would leverage any implementation-defined strict total ordering for pointers.
Resolves#880
`size_bytes()` returns the span's size in bytes.
Assuming the span was constructed with an accurate size parameter, the check `size() < dynamic_extent / sizeof(element_type)` isn't required, since `size_t(-1)` (which is `dynamic_extent`) represents the size of the address space, so the number of bytes will never exceed it and in practice won't even come close.
Otherwise, it is not actually feasible to detect cases when the size parameter does not correspond to the dimensions of the underlying data pointer. In these cases, the relationship `size() < dynamic_extent / sizeof(element_type)` is simply one of many ways in which the `size()` could be incorrect, and serves no necessary purpose.
Resolves#1012
The `#i13-do-not-pass-an-array-as-a-single-pointer` anchor seems to be auto generated based on the title of the section. The `#Ri-array` anchor is explicitely written in the source, so this should be a better link.
https://github.com/microsoft/GSL/issues/1075
- Add `static_assert` because we only support C style array `at` for up to half of the address space.
- Add `std::` before `size_t`.
- tests:
- Add `#include <exception>`
- Implement `span_tests` `interop_with_gsl_at` like `at_tests` `std_span`
Add a `linguist-language` Git attribute that matches the files at `include/gsl` and sets their language to C++. Without this override, these files are not detected as C++ code by [GitHub's Linguist](https://github.com/github/linguist) (likely due to lacking any file extensions).
This will cause GitHub.com to count these files correctly as C++ code and do syntax highlighting when browsing the repo.
**Linguist breakdown results**
Before:
<details>
```
$ docker run --rm -v $(pwd):$(pwd) -w $(pwd) -t linguist github-linguist --breakdown
91.57% 152148 C++
8.43% 14011 CMake
CMake:
CMakeLists.txt
cmake/gsl_functions.cmake
cmake/gsl_install.cmake
include/CMakeLists.txt
tests/CMakeLists.txt
C++:
tests/algorithm_tests.cpp
tests/assertion_tests.cpp
tests/at_tests.cpp
tests/byte_tests.cpp
tests/deathTestCommon.h
tests/no_exception_ensure_tests.cpp
tests/notnull_tests.cpp
tests/owner_tests.cpp
tests/span_compatibility_tests.cpp
tests/span_ext_tests.cpp
tests/span_tests.cpp
tests/strict_notnull_tests.cpp
tests/utils_tests.cpp
```
</details>
After:
<details>
```
$ docker run --rm -v $(pwd):$(pwd) -w $(pwd) -t linguist github-linguist --breakdown
94.16% 225699 C++
5.84% 14011 CMake
CMake:
CMakeLists.txt
cmake/gsl_functions.cmake
cmake/gsl_install.cmake
include/CMakeLists.txt
tests/CMakeLists.txt
C++:
include/gsl/algorithm
include/gsl/assert
include/gsl/byte
include/gsl/gsl
include/gsl/gsl_algorithm
include/gsl/gsl_assert
include/gsl/gsl_byte
include/gsl/gsl_narrow
include/gsl/gsl_util
include/gsl/narrow
include/gsl/pointers
include/gsl/span
include/gsl/span_ext
include/gsl/string_span
include/gsl/util
tests/algorithm_tests.cpp
tests/assertion_tests.cpp
tests/at_tests.cpp
tests/byte_tests.cpp
tests/deathTestCommon.h
tests/no_exception_ensure_tests.cpp
tests/notnull_tests.cpp
tests/owner_tests.cpp
tests/span_compatibility_tests.cpp
tests/span_ext_tests.cpp
tests/span_tests.cpp
tests/strict_notnull_tests.cpp
tests/utils_tests.cpp
```
</details>
- `fail_fast`,`basic_string_span` and `basic_zstring_span` are not declared in the headers any more.
- Name the exporting header file for all types in `GSL.natvis`.
This solves issue #1070 and removes the class `string_span`. The only content remaining in the header file `gsl/string_span` is the `*zstring` types.
This also removes the `string_span_tests.cpp` unit tests as these were only for the deprecated `string_span` class.
Co-authored-by: Werner Henze <werner.henze+gitcommits@posteo.de>
