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

Thu Nov 4 01:23:44 PDT 2021

David,

Thanks a lot for the help, we now have a Forum where we can ask Autosar
C++14-related questions directly to MISRA! This is great news.
https://forum.misra.org.uk/forum-185.html

Regarding licensing, I'll wait for the reply from the Autosar admin email
address. Reading about similar questions in the MISRA forums, I reach your
same conclusion - we may only refer to the rule numbers without mentioning
the rule text. This is done in order to preserve the original text (one
source of truth) to avoid confusion, which I think makes sense. I hope
Autosar has a similar view.

Best regards,
Carlos

On Tue, Nov 2, 2021 at 6:34 PM Chris Tapp (MISRA CPP Chair) <
chair.cpp at misra.org.uk> wrote:

> Hi Carlos,
>
> I am not able to comment on the legal position with respect to Autosar.
> The request you have sent to their admin email address is the best way to
> get an answer on that.
>
> From the MISRA perspective, I can put you in touch (off list) with the
> relevant contact so you can discuss how to do this. From memory, I think it
> is ok to add the checks (and quote the guideline numbers), but a license
> would be needed if the MISRA headline text (“Don’t do this…”) is used.
>
> I am happy for technical questions to be sent directly to me, but it is
> better for the MISRA user community if they are posted on the forum. New
> questions (in the MISRA C++ section) currently get reviewed every week or
> so at the moment, but feel free to send me an email as well so I can make
> sure any you add are actioned as soon as possible. I’ve located the one you
> posted re Autosar and will post a reply.
>
> Chris
>
> —
>
> Chris Tapp, MISRA C++ Chair
>
> On 1 Nov 2021, at 12:20, Carlos Galvez <carlosgalvezp at gmail.com> wrote:
>
> Chris,
>
> Thanks a lot for the reply, it's really great to have a feedback loop with
> MISRA. As a starting point we are trying to understand if it's OK to
> implement open-source clang-tidy checks based on the Autosar C++14
> guidelines, from a legal/license point of view. I've sent a mail about this
> to admin at autosar.org - is that correct or should I direct my questions to
> MISRA directly?
>
> Regarding technical questions, should we direct them to your email
> directly, via this mailing list or by some other means? There's also the MISRA
> forums <https://forum.misra.org.uk/> which I think work pretty well, even
> though the feedback time is rather high. I have asked
> <https://forum.misra.org.uk/thread-1586.html> there whether it makes
> sense to post Autosar-related questions or not.
>
> Best regards,
> Carlos
>
> On Mon, Nov 1, 2021 at 11:56 AM Chris Tapp (MISRA CPP Chair) <
> chair.cpp at misra.org.uk> wrote:
>
>> Hi All,
>>
>> I am the current chair of the MISRA C++ Working Group.
>>
>> As a bit of background, the Autosar guidelines are currently being merged
>> into an updated MISRA C++ document (support for C++17, with C++20 and later
>> planned). Autosar C++ will be retired when this work is complete, with
>> Autosar moving to the updated MISRA guidelines. There will be significant
>> differences between the MISRA and Autosar documents - for example, MISRA
>> will not be including any guidelines that are related to (software
>> development) process, coding style nor most of those related to software
>> design.
>>
>> As part of this ongoing work, a number of the Autosar team have joined
>> the MISRA group. I therefore have good contacts with Autosar and the people
>> who developed Autosar C++14. I would be more than happy to answer any
>> questions that you may have related to Autosar or MISRA.
>>
>> Note - it may also be worth looking at MISRA Compliance:2020 (
>> https://www.misra.org.uk/app/uploads/2021/06/MISRA-Compliance-2020.pdf),
>> as this defines what is required to make a claim of "MISRA compliance”.
>>
>> Chris
>> —
>> <MISRA_LOGO x.png>
>>
>> Chris Tapp, MISRA C++ Chair
>>
>> On 28 Oct 2021, at 13:55, Aaron Ballman via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>> On Wed, Oct 27, 2021 at 5:12 PM Carlos Galvez <carlosgalvezp at gmail.com>
>> wrote:
>>
>>
>> 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
>>
>>
>>
>> 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
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>> The MISRA Consortium is a limited company registered in England and Wales
>> Registered number: 13152596
>> Registered office: 1 St James Court Whitefriars, Norwich, Norfolk,
>> England, NR3 1RU
>> VAT number GB 377 2093 78
>>
>
>
> The MISRA Consortium is a limited company registered in England and Wales
> Registered number: 13152596
> Registered office: 1 St James Court Whitefriars, Norwich, Norfolk,
> England, NR3 1RU
> VAT number GB 377 2093 78
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211104/33606a40/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MISRA_LOGO x.png
Type: image/png
Size: 2907 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211104/33606a40/attachment-0001.png>