[clang] [Clang] [Contracts] Design Doc (PR #229978)

[via cfe-commits]

================
@@ -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. 
----------------
EricWF wrote:

We should settle the flag names now. Whatever the first Sema PR adds is going to stick.

I'd use `-fcontracts` as the experimental gate. Making it cc1-only to start is fine if you prefer. The doc should say whether `contract_assert` is a keyword in `-std=c++26` without the flag.

For the evaluation semantic, I'd use `-fcontract-evaluation-semantic={ignore,observe,enforce,quick_enforce}`, defaulting to `enforce`. That matches GCC's P2900 implementation and Josh's P3850 branches.

I wouldn't use `-fcontract-mode=`. GCC 13 uses that spelling as an on/off switch. "Mode" is overloaded across the papers, and we'll want P3595-style per-kind configuration later without renaming the flag.


https://github.com/llvm/llvm-project/pull/229978