Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSL_SUPPRESS(y) expands to [[gsl::suppress("x")]] for clang #1130

Closed
edgchen1 opened this issue Aug 22, 2023 · 5 comments · Fixed by #1133
Closed

GSL_SUPPRESS(y) expands to [[gsl::suppress("x")]] for clang #1130

edgchen1 opened this issue Aug 22, 2023 · 5 comments · Fixed by #1133

Comments

@edgchen1
Copy link
Contributor

Here's the definition of GSL_SUPPRESS:

GSL/include/gsl/assert

Lines 48 to 50 in 4300304

#if defined(__clang__)
#define GSL_SUPPRESS(x) [[gsl::suppress("x")]]
#else

This always expands to [[gsl::suppress("x")]] because the "x" string literal won't be replaced.

We probably want something like this instead:

#define GSL_SUPPRESS(x) [[gsl::suppress( #x )]]
@dmitrykobets-msft
Copy link
Member

@edgchen1 good catch. If you'd like to tackle this one you can assign the issue to yourself.

note: whoever ends up implementing this will want to add a test-case for the suppression behavior.

@edgchen1
Copy link
Contributor Author

Any suggestions on how to add a test for it? I'm not too familiar with the existing test setup, but from a quick look it wasn't obvious to me.

@beinhaerter
Copy link
Contributor

Good question. I was thinking about compiling with -Werror and either triggering or suppressing the warning. I googled a bit and found
https://stackoverflow.com/questions/30155619/expected-build-failure-tests-in-cmake
https://ibob.bg/blog/2022/10/04/testing-build-failure-with-cmake/#the-final-solution
https://github.com/iboB/icm/blob/master/icm_build_failure_testing.cmake

I am not a cmake expert and right now I don't want to invest more time to try to implement the tests.

From a look into the test code here I found that there are some #ifdef CONFIRM_COMPILATION_ERRORS, but I don't see how and where that value is defined. And even iif it was, it would cover multiple test cases and the test would succeed if any of these tests failed to compile. I would expect the test to succeed if all of these tests fail to compile.

I hope that dmitrykobets-msft will accept a fix even without an extra test and that he comes up with an idea how to get the test case working. When the test case is implemented, also the #ifdef CONFIRM_COMPILATION_ERRORS could be changed into individual test cases.

@dmitrykobets-msft
Copy link
Member

Fair enough; looks like we will want some form of compilation-failure testing, and currently CONFIRM_COMPILATION_ERRORS is non-functional (and has been for a while); this is something we'll want to address in the future.
The change suggested in this issue is small and simple enough, and touches an area that is not expected to change anytime soon, so we can skip adding automated testing.

@edgchen1
Copy link
Contributor Author

edgchen1 commented Sep 2, 2023

Thanks for the input @beinhaerter and @dmitrykobets-msft.

I created a small PR (#1133) with just the change in this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants