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.

Sign up for GitHub

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

Jump to bottom

Crash when parsing capability qualifier with typeof #710

Open
arichardson opened this issue Jul 6, 2023 · 0 comments
Open

Crash when parsing capability qualifier with typeof #710

arichardson opened this issue Jul 6, 2023 · 0 comments

Comments

@arichardson
Copy link
Member 

struct s { int i; };
static struct s *global_sptr = 0;
static __capability typeof(global_sptr) global_scap = 0;

Fails with
Assertion isDeclRep((TST) TypeSpecType) || TypeSpecType == TST_typename' failed.`

Interestingly using int instead of a struct works as expected:

static int *global_intptr = 0;
static __capability typeof(global_intptr) global_intcap = 0;
_Static_assert(__builtin_types_compatible_p(typeof(global_intptr), int *), "");
_Static_assert(__builtin_types_compatible_p(typeof(global_intcap), int *__capability), "");
arichardson added a commit to arichardson/llvm-project that referenced this issue Jul 6, 2023
@arichardson
Extend the __capability qualifier tests for typeof() and decltype()
3baec7f 
This exposed a new crash: CTSRD-CHERI#710
arichardson added a commit to arichardson/llvm-project that referenced this issue Jul 6, 2023
@arichardson
Extend the __capability qualifier tests for typeof() and decltype()
9e2180a 
This exposed a new crash: CTSRD-CHERI#710
arichardson added a commit that referenced this issue Jul 7, 2023
@arichardson
Extend the __capability qualifier tests for typeof() and decltype()
4fa1628 
This exposed a new crash: #710
@jrtc27 jrtc27 mentioned this issue Aug 22, 2023
Closed
jrtc27 added a commit that referenced this issue Sep 2, 2023
@jrtc27
[clang] Extend pointer interpretation handling to track explicitness
f2597f7 
We need a new type like DependentPointerType for non-dependent contexts
that can track __capability applied to things like typeof(...) in order
to have a corresponding TypeLoc for the qualifier, otherwise things like
TypeSpecLocFiller get out of sync and, in some cases assert (in other
cases silently use the wrong DeclSpec). However, this then exposes the
fact TypePrinter's PrintingPolicy's SuppressCapabilityQualifier isn't
always able to be set to the right value (e.g. when printing out a
reinterpret_cast<T> to the user, or when dumping the AST), and so we end
up with redundant __capability qualifiers appearing for purecap code in
some cases, and so we need to track alongside the pointer interpretation
whether it was explicit (which also needs care to ensure it doesn't mess
with canonicalisation). Whilst the output is now noisier in cases where
__capability is used in purecap code, this is more faithful to the
source.

The churn in the AST output due to __capability in the source always
being sugar is an unfortunate side-effect, but this should disappear
if llvm/llvm-project#65214 is merged.

Fixes #710
@jrtc27 jrtc27 mentioned this issue Sep 2, 2023
Open
jrtc27 added a commit that referenced this issue Sep 4, 2023
@jrtc27
[clang] Extend pointer interpretation handling to track explicitness
4d71789 
We need a new type like DependentPointerType for non-dependent contexts
that can track __capability applied to things like typeof(...) in order
to have a corresponding TypeLoc for the qualifier, otherwise things like
TypeSpecLocFiller get out of sync and, in some cases assert (in other
cases silently use the wrong DeclSpec). However, this then exposes the
fact TypePrinter's PrintingPolicy's SuppressCapabilityQualifier isn't
always able to be set to the right value (e.g. when printing out a
reinterpret_cast<T> to the user, or when dumping the AST), and so we end
up with redundant __capability qualifiers appearing for purecap code in
some cases, and so we need to track alongside the pointer interpretation
whether it was explicit (which also needs care to ensure it doesn't mess
with canonicalisation). Whilst the output is now noisier in cases where
__capability is used in purecap code, this is more faithful to the
source.

The churn in the AST output due to __capability in the source always
being sugar is an unfortunate side-effect, but this should disappear
if llvm/llvm-project#65214 is merged.

Fixes #710
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@arichardson