C++: Uncomment cases in dbscheme #11799
Merged
Conversation
This file contains hidden or 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
jketema
added
the
depends on internal PR
jketema
force-pushed
the
case-uncomment
branch
5 times, most recently
from
a8cb64f to
c66157e
Compare
jketema
force-pushed
the
case-uncomment
branch
from
1b730ff to
a598f5d
Compare
jketema
force-pushed
the
case-uncomment
branch
3 times, most recently
from
3119041 to
9607c8a
Compare
Note that the builtin types `__int{8,16,32,64}` are not uncommented,
as these are never and could have never been generated by the
extractor.
jketema
force-pushed
the
case-uncomment
branch
from
9607c8a to
c1bc097
Compare
rdmarsh2
approved these changes
Jan 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This uncomments some of the case splits in the C++ dbscheme.
@function.kindand@usertype.kindcannot be uncommented, as that would make them a source of database inconsistencies. Those should be solved first before uncommenting these case splits. I have re-worked them slightly to make uncommenting straightforward.The builtin types
__int{8,16,32,64}are not uncommented, as these are never and could have never been generated by the extractor.The remaining cases that are commented out, are actually not case splits, as they do not refer to definitions of opaque types.
DCA was ran on the internal PR. Test here are expected to fail but should pass on the internal PR.