[cfe-dev] [clang-tidy][RFC] Add Autosar C++14 clang-tidy module?

[Carlos Galvez via cfe-dev]

That's great to hear, thanks! Will give it a kickstart one of these days :)

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.


On Wed, Oct 27, 2021 at 7:47 PM Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Wed, Oct 27, 2021 at 11:29 AM Carlos Galvez via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > Hi!
> >
> > We are following the Autosar C++14 guidelines and were thinking to add a
> clang-tidy module for it and start implementing checks. There's a couple
> local forks with some checks here and there but never made it upstream. I
> believe quite a lot of them are already covered by the existing checks
> (e.g. cppcoreguidelines) so most of the work would be about creating
> aliases and adding some extra configuration.
> >
> > What do you think, would that be ok? Both about adding the Autosar
> module itself, but also making aliases from one coding guideline (e.g.
> cppcoreguidelines) to another coding guideline (autosar). Typically the
> alias is from a non-coding guideline (e.g. bugprone) to a coding guideline
> (cppcoreguidelines).
> >
> > We can of course have our own local fork but it's nice to be able to
> contribute upstream so everyone can benefit. Autosar would fit well
> together with the existing guidelines (CppCoreGuidlines, CERT, HiCPP, etc).
>
> Personally, I'm okay with adding a module for AUTOSAR checks. It's an
> industry standard set of coding conventions like many of the other
> modules we have. However, one issue we've run into with things like
> the C++ Core Guidelines is a lack of a useful feedback loop when there
> are enforcement questions. Do you have contacts with anyone
> maintaining AUTOSAR so that if we run into questions we'll have some
> guidance on how to resolve them?
>
> As for aliases from one coding guideline to another; I think that's
> fine. We already have the issue where changing the primary check may
> cause the alias to no longer be valid, so I don't think this would
> introduce any new problems we don't already have to watch out for. One
> thing that could get a bit weird is with documentation (aliases
> typically automatically redirect back to their primary check, so it
> might be weird to go to the docs for an AUTOSAR check and wind up in
> CERT C++ or something. But if that causes problems in practice, I
> think they can be handled as they come up.
>
> ~Aaron
>
> >
> > Best regards,
> > Carlos
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211027/12b9cb56/attachment.html>