================ @@ -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. ---------------- AaronBallman wrote:
I think it makes sense for `-fcontracts` to be behind `cc1` until we're to the point where it can be used experimentally for more than just internal testing purposes. Then it can be promoted out of `cc1` as it gets closer to production-capable. Once we fully support it, I don't think we need it as a flag unless we want to allow it as a non-conforming extension in older language modes (which is a bridge we can cross later). I think `contract_assert` is only a keyword if the feature is enabled, even in C++26 mode. As for evaluation semantics, I think we should come up with a suggested default value and then propose it to the community with justification for why we think it should be the default. I suspect there will be a handful of things we're going to want to get community input on, and evaluation semantics are one of the more important things (particularly because downstreams will inherit whatever default we pick). Personally, I think `enforce` is a reasonable default semantic to consider, but it also depends very much on the impact to program performance. e.g., if `enforce` means a contract violation handler has to be assumed to trigger and then resume execution, that could cause optimization barriers where we can no longer assume the state of escaped pointers and global data and perhaps `quick_enforce` is a better tradeoff. https://github.com/llvm/llvm-project/pull/229978 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
