> Doesn't this being a gcc plugin make it inherently unattractive?
I'm the author, and even I think so. I'm more of an LLVM fan myself (though I can't not mention David Malcom's work on the GCC Static Analyzer).
(Ideally it wouldn't be a plugin at all, it'd be a language feature. We got Contracts and left out the most useful contract of them all)
Originally, I started it as a Clang plugin, thinking that I could also implement support for the Contracts "[[pre]]" and "[[post]]" specification on top (or at least some minimal implementation of it).
This turned out to be a lot more work.
If people would like to use this from Clang, even without support for regular Contracts, I will publish a compatible Clang plugin.
I think at some point there was support for Contracts in Clang, maybe longer term I'll try to get them working again? (I've no experience here)
(Ideally it wouldn't be a plugin at all, it'd be a language feature. We got Contracts and left out the most useful contract of them all)
Originally, I started it as a Clang plugin, thinking that I could also implement support for the Contracts "[[pre]]" and "[[post]]" specification on top (or at least some minimal implementation of it).
This turned out to be a lot more work.
If people would like to use this from Clang, even without support for regular Contracts, I will publish a compatible Clang plugin.
I think at some point there was support for Contracts in Clang, maybe longer term I'll try to get them working again? (I've no experience here)
https://github.com/arcosuc3m/clang-contracts
This fellow wrote a whole ~200 page thesis on this just as recently as 2018, such a shame for it to go to waste =/
https://e-archivo.uc3m.es/bitstream/handle/10016/29231/TFG_J...