That's great to hear, thanks! Will give it a kickstart one of these days
Excellent, thank you!
You have a very valid point about the feedback loop, and that's one of the pain points of Autosar. Therefore some rules might need to be left out or enforced in a "best effort" way. Or made configurable so that if they are ambiguous they can be enforced following a handful of interpretations. At least Autosar makes it clear which rules are meant to be "automatically enforceable" and which ones aren't. Some rules are also impractical to follow strictly so I can foresee the need for partial deviations via configuration. Autosar also inherits some MISRA rules, for which one can actually ask questions in the MISRA forums directly, so that's good.
Would be interesting to have several companies contributing to it and openly discuss those rules that are more ambiguous or poorly written. Who knows, maybe the Autosar authors come across these checks and help clarifying!
All in all, Autosar is not perfect but it's an important enabler for e.g. the automotive industry to finally leave MISRA C++08 and move to modern C++14. There's plans for new MISRA guidelines covering C++17 but it's unclear when they'll be published, so we need to live with Autosar for a little more.
Agreed, and to be clear, we don't have a requirement that there is a
feedback loop with the proposal authors before adding a new module to
clang-tidy. I mostly brought it up as an existing source of pain with
the C++ Core Guideline checks. I'd like to avoid similar issues with
new modules because lacking a feedback loop makes the code review
process significantly harder when the rule is unclear (which
negatively impacts reviewers, patch authors, and clang-tidy users).
~Aaron