Skip to content

C23 keywords #8623

New issue

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

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

Already on GitHub? # to your account

Merged
merged 1 commit into from
Apr 11, 2025
Merged

C23 keywords #8623

merged 1 commit into from
Apr 11, 2025

Conversation

kroening
Copy link
Member

@kroening kroening commented Apr 9, 2025

This adds scanner, parser and typechecker support for the new C23 keywords.

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@tautschnig
Copy link
Collaborator

Asking here so as not to delay #8621 any further:

  1. In loc(); return conditional_keyword(...); the use of loc(); is unnecessary, we should clean that up.
  2. In make_identifier and also MSC_cpp_keyword we have if(PARSER.cpp98 ... - which seems insufficient as it would not cover the case of PARSER.cpp11 being set instead.

@tautschnig
Copy link
Collaborator

Also, while working on this piece of code we might fix #8308?

@kroening
Copy link
Member Author

kroening commented Apr 9, 2025

Also, while working on this piece of code we might fix #8308?

#8624

@kroening
Copy link
Member Author

kroening commented Apr 9, 2025

  1. In loc(); return conditional_keyword(...); the use of loc(); is unnecessary, we should clean that up.

Yes, some tokens come with an IREP and some don't -- and it's prone to error to keep that in sync. I am minded to give an IREP to all identifier-like tokens to remove that ambiguity.

  1. In make_identifier and also MSC_cpp_keyword we have if(PARSER.cpp98 ... - which seems insufficient as it would not cover the case of PARSER.cpp11 being set instead.

For clarity, could be renamed to cpp98_or_above, but more verbose, or could write cpp98 || cpp11 || ....

@kroening kroening force-pushed the c23-2 branch 2 times, most recently from 67cd3f5 to 1de6619 Compare April 9, 2025 18:27
@tautschnig
Copy link
Collaborator

  1. In loc(); return conditional_keyword(...); the use of loc(); is unnecessary, we should clean that up.

Yes, some tokens come with an IREP and some don't -- and it's prone to error to keep that in sync. I am minded to give an IREP to all identifier-like tokens to remove that ambiguity.

Yes, but not what I was after: conditional_keyword invokes loc() on the if branch, or else make_identifier, which in turn invokes loc() right away. So doing loc(); return conditional_keyword(...) makes that first loc(); call redundant.

@kroening
Copy link
Member Author

kroening commented Apr 9, 2025

Yes, but not what I was after: conditional_keyword invokes loc() on the if branch, or else make_identifier, which in turn invokes loc() right away. So doing loc(); return conditional_keyword(...) makes that first loc(); call redundant.

#8626

@kroening kroening force-pushed the c23-2 branch 3 times, most recently from 54026f1 to 7c8b661 Compare April 9, 2025 22:20
Copy link

codecov bot commented Apr 9, 2025

Codecov Report

Attention: Patch coverage is 78.06452% with 34 lines in your changes missing coverage. Please review.

Project coverage is 80.37%. Comparing base (0b000a3) to head (b1808c3).
Report is 2 commits behind head on develop.

Files with missing lines Patch % Lines
src/ansi-c/expr2c.cpp 40.00% 12 Missing ⚠️
src/ansi-c/scanner.l 70.83% 7 Missing ⚠️
src/ansi-c/c_typecheck_type.cpp 78.57% 6 Missing ⚠️
src/ansi-c/parser.y 76.92% 6 Missing ⚠️
src/ansi-c/gcc_version.cpp 50.00% 2 Missing ⚠️
src/util/config.cpp 75.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #8623      +/-   ##
===========================================
- Coverage    80.38%   80.37%   -0.02%     
===========================================
  Files         1686     1686              
  Lines       206764   206872     +108     
  Branches        75       73       -2     
===========================================
+ Hits        166207   166268      +61     
- Misses       40557    40604      +47     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@kroening kroening force-pushed the c23-2 branch 4 times, most recently from ddec5f3 to a556e81 Compare April 10, 2025 01:51
Comment on lines +1 to +17
// C23 introduces the "static_assert" keyword.

struct S
{
// Visual Studio does not support static_assert in compound bodies.
#ifndef _MSC_VER
static_assert(1, "in struct");
#endif
int x;
} asd;

static_assert(1, "global scope");

int main()
{
static_assert(1, "in function");
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this go in the ansi-c regression test folder instead of cbmc?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that was my first attempt. But we run various compilers over that folder, and they don't do C23.

Comment on lines +1 to +23
typedef int INTTYPE;

int func1();

// C23 typeof
typeof(int) v1;
typeof(INTTYPE) v2;
typeof(v2) v3;
typeof(1 + 1) v4;
typeof(1 + 1 + func1()) v5;
const typeof(int) v6;
typeof(int) const v7;
static typeof(int) const v8;
static typeof(int) const *v9;
static volatile typeof(int) const *v10;

void func2(typeof(int) *some_arg)
{
}

int main()
{
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably go in ansi-c?

return integer2string(binary2integer(binary, false));
}
else
return convert_norep(src, precedence);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think previously this would handle __CPROVER_bitvector in some way?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those map to signedbv/unsignedv.

@kroening kroening force-pushed the c23-2 branch 4 times, most recently from 45c3fe6 to 5a39bdd Compare April 10, 2025 14:22
@kroening kroening force-pushed the c23-2 branch 2 times, most recently from 669e233 to 0c3d48c Compare April 10, 2025 14:43
@kroening kroening force-pushed the c23-2 branch 4 times, most recently from 6ee8f9d to d070209 Compare April 10, 2025 18:44
This adds scanner, parser and typechecker support for the new C23 keywords.
exprt assertion =
typecast_exprt::conditional_cast(code.op0(), bool_typet());
simplify(assertion, ns);
INVARIANT_WITH_DIAGNOSTICS(
!assertion.is_false(),
"static assertion " + id2string(get_string_constant(code.op1())),
"static assertion is false",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, shouldn't we keep the message when there is one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should never be executed, and is presumably dead code.

@kroening kroening merged commit 5dc709d into develop Apr 11, 2025
39 of 41 checks passed
@kroening kroening deleted the c23-2 branch April 11, 2025 14:24
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants