-
Notifications
You must be signed in to change notification settings - Fork 741
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
Add "gsl" to #includes #1184
Merged
carsonRadtke
merged 1 commit into
microsoft:main
from
tiagomacarios:user/tiagoma/qualify_includes
Jan 7, 2025
Merged
Add "gsl" to #includes #1184
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
#pragma once | ||
#pragma message( \ | ||
"This header will soon be removed. Use <gsl/zstring> instead of <gsl/string_span>") | ||
#include "zstring" | ||
#include "gsl/zstring" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, include search order is implementation defined. But from what I see from current compilers:
Includes with "" are searched in the current path first. In the current path here there is no subfolder "gsl/".
If at all then it should be <gsl/...>, but <> is for system/external includes, not for include from the same project.
In my opinion this is a change that makes things worse, not better. I bet it's a problem with the Office build setttings and it should be fixed there, not here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://learn.microsoft.com/en-us/cpp/build/reference/i-additional-include-directories?view=msvc-170
So the Office code needs to
#include <gsl/...>
, but the GSL itself should#include "..."
. If GSL itself does#include "gsl/..."
then this fails and what is found then depends on the parent include files and if they have a gsl subfolder. If that all fails step three triggers. That is a lot of fragile searching. On the other side#include "..."
just finds the file aside the GSL file that is doing the include.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What we were observing is that gsl/algorithm@21 and gsl/gsl@25 where including the C++20 std::span headers. Our code does use the fully qualified include.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am inclined to revert this PR. I fear we may have blocked customers from installing
gsl
under a different name (for example, they might#include <ms-gsl/gsl>
).I don't want reverting this PR to mean that Office needs to apply a patch every time y'all consume GSL. @tiagomacarios Can you link to a pipeline where the wrong
span
was included? Maybe there are some clues there that will help us understand why.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@beinhaerter Office uses header units. When header units are enabled the compiler prefers a header map (not in the docs you linked). It is unclear if this is by design or not. We are following up with the compiler team.
Anyway, path should be fully qualified. See boost or any other large opensource project for examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@carsonRadtke thoughts on replacing quotes with angle brackets? I presume this might make @beinhaerter more comfortable with the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My reading of the docs is different. The docs don't say that the parent directory of the current include is searched. It says that the directory of the parent include is searched. Given
gsl/assert will be searched as:
So shouldn't this work?
How is the import done in Office for span? And what is provided for the headerUnit of gsl/span?
Do you have a minimal compilable example where the wrong behaviour can be observed? Otherwise I will try to reproduce it myself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay - this fell off my radar last week.
You're right, I misinterpreted that.
Yes, this would work; Office is in the process of moving to header units for library dependencies, but the process takes time.
@beinhaerter If you believe this new behavior is bad enough to warrant a change, we can do one of the following:
<gsl/...>
(as was discussed earlier)"./..."
(as was suggested by the modules FE dev in an internal chat)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My two cents:
As the GSL is there to support the guidelines it should itself follow the guidelines. That means GSL should
#include "..."
and not#include <...>
.The MS Office team has a solution that works with GSL doing
#include "span"
, they only need to implement it. Until then they could modify their local copy of the GSL.So I would revert the change and let the Office team solve the problem on their side (either in the build system or in their GSL copy). I would not see a reason to solve their problem in the open source GSL project.
If you want to wait with reverting the change until the Office team is ready, then an
#include "./span"
looks appealing because it follows the guidelines (even if the "./" looks a bit strange) and it works for the Office team. As of today I revert the change in my local copy of GSL. If you want to go the "./span" way I would just use that original upstream code.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will create a PR that reverts this PR and takes this approach. @tiagomacarios Any objections?