Contracts nightly #9

EricWF · 2025-08-02T21:10:33Z

No description provided.

…e initial implementation

The template stuff is a bit of a hack. I'm considering simply inserting the statements into the function body and letting the existing code handle the rest. Also add some cheaky diagnostics, fix a few name lookup bugs, and delete some old code.

There are also various experiements that need cleaning up, specifically around builtins and source location.

Some work on constification, but a bunch of experiment that still needs to be undone. The addition of -fclang-contract-groups=foo=<semantic>, which still needs better integrating with -fcontract-evaluation-semantic=. The [[clang::contract_group("foo.bar")]] stuff works really well. I'll be happy to try it in libc++. What still needs to be done includes: * Coming up with a proper descriptor/format for the compiler-stl interface. It seems to me we'll want the ABI to be able to evolve over time, and so we should pass a pointer to data + data descriptor of some kind so that the STL can parse version of the header from different compilers & versions. * Everything to do with parsing pre/post in inline member functions. * Contract redeclaration checking. * Constifying implicit this. * Code gen & constant evaluation for result names (and representation too). * Cleanup around experiments for source location & constification.

…e initial implementation

The template stuff is a bit of a hack. I'm considering simply inserting the statements into the function body and letting the existing code handle the rest. Also add some cheaky diagnostics, fix a few name lookup bugs, and delete some old code.

There are also various experiements that need cleaning up, specifically around builtins and source location.

Some work on constification, but a bunch of experiment that still needs to be undone. The addition of -fclang-contract-groups=foo=<semantic>, which still needs better integrating with -fcontract-evaluation-semantic=. The [[clang::contract_group("foo.bar")]] stuff works really well. I'll be happy to try it in libc++. What still needs to be done includes: * Coming up with a proper descriptor/format for the compiler-stl interface. It seems to me we'll want the ABI to be able to evolve over time, and so we should pass a pointer to data + data descriptor of some kind so that the STL can parse version of the header from different compilers & versions. * Everything to do with parsing pre/post in inline member functions. * Contract redeclaration checking. * Constifying implicit this. * Code gen & constant evaluation for result names (and representation too). * Cleanup around experiments for source location & constification.

This allows better versioning, and also prevents us from clobbering every registery. (though that latter case is likely not too impactful).

Also, re-enable the exception handling tentatively.

…ts-reset

The tests haven't been written yet, since I need to perform a merge before they'll build (silly upstream libc++, breaking the test suite for unknown reasons)

cor3ntin

I am far from having done a complete pass, but here are some comments.
Chopping this in manageable pieces will be necessary I'm afraid, Github can barely render the PR and reviewers will be discouraged by the sheer size of it all.

Changes to source location could be a PR and then maybe we want to start with just contract_assert, even if i understand it would be annoying for you.

Non essentials (ast matchers for examples) can be separate PRs.
Everything lamba related can also be separated out.

I will keep reviewing today or tomorrow

cor3ntin · 2025-08-03T07:00:17Z

clang/include/clang/AST/ASTContext.h

@@ -1287,6 +1287,10 @@ class ASTContext : public RefCountedBase<ASTContext> {
  // The decl is built when constructing 'BuiltinVaListDecl'.
  mutable Decl *VaListTagDecl = nullptr;

+  // Decl used to define the datastructure for the contract violation object


Suggested change

// Decl used to define the datastructure for the contract violation object

// Decl used to define the data structure for the contract violation object

cor3ntin · 2025-08-03T07:01:21Z

clang/include/clang/AST/ASTContext.h

@@ -1287,6 +1287,10 @@ class ASTContext : public RefCountedBase<ASTContext> {
  // The decl is built when constructing 'BuiltinVaListDecl'.
  mutable Decl *VaListTagDecl = nullptr;

+  // Decl used to define the datastructure for the contract violation object
+  // used for C++ contracts
+  mutable Decl *BuiltinContractViolationRecordDecl = nullptr;


Any reason not to make that a RecordDecl directly?

cor3ntin · 2025-08-03T07:05:02Z

clang/include/clang/AST/ASTNodeTraverser.h

      if (isa<DeclStmt, GenericSelectionExpr, RequiresExpr,
-              OpenACCWaitConstruct, SYCLKernelCallStmt>(S))
+              OpenACCWaitConstruct, SYCLKernelCallStmt, ContractStmt>(S))


Maybe we should just make expressions children. It's not yet clear to me why they should not be, as I do a linear read through

cor3ntin · 2025-08-03T07:07:03Z

clang/include/clang/AST/DeclCXX.h

+///   int foo() post(r : r > 0);
+///
+/// Where `r` refers to the value returned by the function
+class ResultNameDecl : public ValueDecl {


I think this should be called ContractXXXX. Maybe ContractNamedReturnDecl

cor3ntin · 2025-08-03T07:07:47Z

clang/include/clang/AST/Decl.h

-  // qualifier, to be used for the (uncommon) case of out-of-line declarations
-  // and constrained function decls.
+  // qualifier, to be used for the (uncommon) case of out-of-line declarations,
+  // constrained function decls or functions with contracts.


Suggested change

// constrained function decls or functions with contracts.

// constrained function decls or functions with pre/post conditions.

cor3ntin · 2025-08-03T10:08:36Z

clang/include/clang/Basic/TokenKinds.def

@@ -287,6 +290,7 @@ PUNCTUATOR(greatergreatergreater, ">>>")
 //                which are heavily based on AltiVec
 //   KEYBORLAND - This is a keyword if Borland extensions are enabled
 //   KEYCOROUTINES - This is a keyword if support for C++ coroutines is enabled
+//   KEYCONTRACTS - This is a keyword if support for C++ contracts is enabled


In the upstream version I think

we want to put contracts behind the C++26 flags

allow them in all c++ versions (without flag) once they are a bit baked

cor3ntin · 2025-08-03T10:09:10Z

clang/include/clang/Driver/Options.td

+// C++ Contracts
+defm contracts : BoolFOption<"contracts",
+  LangOpts<"Contracts">, DefaultFalse,
+  PosFlag<SetTrue, [], [ClangOption, CC1Option, CLOption],
+          "Enable support for C++ Contracts">,
+  NegFlag<SetFalse, [], [ClangOption, CC1Option]>>;
+


Cf above, lets forgo that for now

cor3ntin · 2025-08-03T10:09:39Z

clang/include/clang/Driver/Options.td

+def fcontract_group_evaluation_semantic_EQ : CommaJoined<["-"], "fcontract-group-evaluation-semantic=">,
+  Visibility<[ClangOption, CC1Option]>,
+  HelpText<"Clang extension. Enable or disable contracts by group. The argument is a comma-separated "
+           "sequence of one or more group names, each prefixed by '+' or '-'.">;
+
+defm contract_exceptions : BoolFOption<"contract-exceptions",
+  LangOpts<"ContractExceptions">, DefaultTrue,
+  PosFlag<SetTrue, [], [ClangOption],
+          "Enable contract violation on exception">,
+  NegFlag<SetFalse, [], [ClangOption, CC1Option],
+    "Disable contract violations on exception">>;


Can we do that in a subsequent PR?

cor3ntin · 2025-08-03T10:10:37Z

clang/include/clang/Parse/Parser.h

+  std::optional<ContractKind> getContractKeyword(const Token &Token) const;
+  std::optional<ContractKind> getContractKeyword() const {
+    return getContractKeyword(Tok);
+  }
+  bool isFunctionContractKeyword() const {
+    return isFunctionContractKeyword(Tok);
+  }
+  bool isFunctionContractKeyword(const Token &Token) const {
+    return getContractKeyword(Token).value_or(ContractKind::Assert) !=
+        ContractKind::Assert;
+  }
+
+  bool isAnyContractKeyword(const Token &Token) const {
+    return getContractKeyword(Token).has_value();
+  }


Cf above, lets keep assert separate from pre/post

cor3ntin · 2025-08-03T10:12:09Z

clang/include/clang/Sema/Scope.h

@@ -42,7 +43,7 @@ class Scope {
 public:
  /// ScopeFlags - These are bitfields that are or'd together when creating a
  /// scope, which defines the sorts of things the scope contains.
-  enum ScopeFlags {
+  enum ScopeFlags : unsigned long {


Maybe we want to introduce an alias for the underlying type

cor3ntin · 2025-08-04T15:14:13Z

clang/include/clang/Basic/ContractOptions.h

+enum class ContractEmissionStyle {
+  /// Emit the contract at every call site, in the caller.
+  InCaller,
+
+  /// Emit the contract with the function definition.
+  InDefinition,
+};


Can we focus on callee side initially?

cor3ntin · 2025-08-04T15:14:34Z

clang/include/clang/Basic/ContractOptions.h

+enum ContractScopeOffset {
+  CSO_ParentContext,
+  CSO_FunctionContext
+};
+


Lets use a scoped enum here

cor3ntin · 2025-08-04T15:17:21Z

clang/include/clang/Basic/DiagnosticSemaKinds.td

+  "woops... FIXME(EricWF): %0"
+>, InGroup<EricWFFixme>;
+
+def err_result_name_shadows_param : Error<


Can we be more consistent about using _contract_ in these diags?

cor3ntin · 2025-08-04T15:18:03Z

clang/include/clang/Basic/DiagnosticSemaKinds.td

+def err_result_name_shadows_param : Error<
+  "declaration of result name %0 shadows parameter">;
+def err_void_result_name : Error<
+  "result name %0 cannot be used with a void return type">;


used? declared? introduced?

"result name in the post condition of a function with a void return type" maybe

cor3ntin · 2025-08-04T15:22:27Z

clang/include/clang/Basic/DiagnosticSemaKinds.td

+def err_contract_violation : Error<"contract %select{precondition|postcondition|assertion}0 failed%select{: %2|}1">;
+def warn_contract_violation : Warning<"contract %select{precondition|postcondition|assertion}0 failed%select{: %2|}1">,
+    InGroup<ContractViolation>;
+
+def err_contract_requirement_failed : Error<
+  "%select{precondition|postcondition|contract assertion}0 failed due to requirement '%1'%select{: %3|}2">;
+def warn_contract_requirement_failed : Warning<
+  "%select{precondition|postcondition|contract assertion}0 failed due to requirement '%1'%select{: %3|}2">,
+  InGroup<ContractViolation>;


None of these are (nor can) ever be used, right?

cor3ntin · 2025-08-04T15:37:42Z