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

[Carlos Galvez via cfe-dev]

> I like the idea of adding an AUTOSAR module to clang-tidy!
Great to hear more positive impressions from the community!

> I know of at least two projects which have some work done already
Thanks for the info. The Google SoC and Bareflank repos are the ones I
referred to as "a couple of forks here and there", didn't know they are
actually the same! I wonder how they dealt with the AUTOSAR license. Thanks
for the video, very interesting talk. One point that was made there was
that perhaps clang-tidy is not the best implementation choice - Clang and
AST visitors are needed to implement the more complex rules. As a newbie I
can't really comment on that, hopefully someone knows better? From a
"design" point of view I think it fits better in clang-tidy together with
the other coding guidelines.

> is there a reason why there are no ambitions to add another module for
the MISRA guidelines?
I suppose nobody has brought it up yet? The current limitation of MISRA is
that you need to actually buy the document, whereas AUTOSAR is publicly
available. On the other hand, MISRA has a clear, established way forward
regarding open-source checkers - you are allowed to mention the rule
number, but not the complete rule text. This is mostly to make sure there
is "one source of truth", instead of inaccurate reproductions. You can read
more about it here: https://forum.misra.org.uk/thread-884.html

In theory (I haven't tried it myself) there's already MISRA support in an
open-source checker - cppcheck: https://cppcheck.sourceforge.io/misra.php
The way it works is that if you want to read the rule text, you need to
purchase (I presume) a rules.txt file and pass it to cppcheck so it can
print the contents.

I suppose that could work here as well, but I think the development process
would be rather awkward. Not possible to document what a given rule is
about, and only a select group  of people who have purchased the document
could actually review the patches. This would probably slow down
development significantly. AUTOSAR would be easier to develop since
everyone can easily contribute based on the publicly available document. I
wonder if there are different licensing models that forbid inaccurate
reproduction and yet allow the documents to be publicly available.

I am still waiting for a reply from AUTOSAR in order to get their approval
for adding these checks to clang-tidy.

Best regards,
Carlos



On Sat, Nov 6, 2021 at 9:54 PM Danny Mösch via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I like the idea of adding an AUTOSAR module to clang-tidy!
>
> I know of at least two projects which have some work done already. The
> first one was started in the context of Google Summer of Code. You can find
> the final report at
> https://docs.google.com/document/d/1r6H5eYOji3mytkdpNJFPuc4PdmE2ZbrFeNAhEqkQIpU/edit.
> Some rules have already been implemented in an LLVM fork at
> https://github.com/Bareflank/llvm-project as mentioned in the report. The
> second one is a commercial project which has been presented at the 2020
> Developers Meeting: https://www.youtube.com/watch?v=-6dL-7xkIV0. At the
> time of the presentation it was not quite clear whether the source code
> will be open-sourced at some point.
>
> > 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.
>
> Talking about MISRA, is there a reason why there are no ambitions to add
> another module for the MISRA guidelines? I would be very interested in
> clang-tidy being able to check for MSRA rules, too. Is it because the
> guidelines have to be licensed/bought? Is it not allowed to make them
> public in any way? Does anyone know?
>
> Greetings,
> Danny
> _______________________________________________
> 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/20211107/ec9ff137/attachment.html>