================ @@ -0,0 +1,943 @@ +# Introduction + +This is a high level design documentation for Contracts implementation in Clang. +This summarized experiences from several implementors in seperate branches. + +This is also tend to be some developer policy/guide of contracts for how should clang +developers continue working on this. + +## High Level Developing Style + +We plan to implement contracts in different small PRs. We don't want to implement +contracts in a single PR. Smaller PR helps reviewers to understand the patch and give +higher quality reviewers. Samller PR is also easier for testers to test and find the +problems. + +The implementation contracts is marked as experimental before we announce it is +implemented completely. + +### ABI + +We'd like to keep ABI unstable during the experimental process. We all understand +ABI's importance. But getting consensus for ABI needs a long time. We prefer to +move faster instead of waiting the consensus for ABI consensus. + +For GCC/libstdc++ interoperability, we need to identify the ABI revision +which a toolchain targets. We shouldn't assume that one experimental GCC ABI +will remain unchanged. + +### Driver flags + +Before we think the support of contracts are minimal usable, users are unable +to get access to contracts unless users pass `-Xclang` explicitly. + +## AST structure ---------------- EricWF wrote:
Serialization, modules, and ODR need their own section in the doc. The first AST PR should serialize the new nodes. `ASTReader` has to merge closure types inside predicates across TUs. The [dcl.contract.func]p4-5 check across modules is an ODR check and has to tolerate parameter renaming, for example by hashing parameters by index. The evaluation semantic shouldn't effect PCM compatibility. The semantic in effect where a module is consumed is the one that matters: checks in inline functions and templates are emitted in the consumer's TU, and anything the consumer evaluates itself should use the consumer's semantic. Your branch can't do that today because Sema builds the handler body per contract and builds nothing under `ignore` (`BuildContractHandlerBody`), so the AST itself differs by mode. That's why `ContractViolationMode` had to be NotCompatible, which means one PCM per semantic. If the AST is the same under every semantic and CodeGen picks the semantic when it emits the check, that restriction goes away. The module's own compile-time evaluations still happen at module build time under the module's semantic (static_asserts, template arguments, `if constexpr`, constexpr initializers), and that's fine; it's that TU's semantic like any other TU. What the PCM should do is record which semantic it was built with, so module-owned entities that a consumer evaluates later use the module's semantic rather than whichever consumer happens to evaluate them first. I'd like to see this in the doc; you know the modules code better than any of us. https://github.com/llvm/llvm-project/pull/229978 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
