This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Adding Zircon checker for std namespace
AbandonedPublic

Authored by juliehockett on Oct 30 2018, 12:30 PM.

Details

Summary

Adds a checker to warn against using the std namespace, as Zircon's kernel lib++ policy does not allow it. Written documentation of the policy is not yet published, I will add the link when it is.

Diff Detail

Event Timeline

juliehockett created this revision.Oct 30 2018, 12:30 PM
JonasToth set the repository for this revision to rCTE Clang Tools Extra.
JonasToth removed a subscriber: JonasToth.
JonasToth added inline comments.Oct 30 2018, 1:38 PM
clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.cpp
30

please do not use auto here as the type is not clear, same below (line 32 right now)

32

The second sentence sounds a bit weird. I think you can even ellide it completely, as the first sentence does clarify quite well.

72

Please create a StringRef for the diagnostic message and reuse that.

Did you consider merging all Decl classes if you just use getNodeAs<Decl>("common_decl_name")?

clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.h
2

There was a bug in the template, please add a blank after clang-tidy but keep the total length.

clang-tools-extra/clang-tidy/zircon/ZirconTidyModule.cpp
30

please keep lexigraphical ordering.

clang-tools-extra/docs/clang-tidy/checks/zircon-no-std-namespace.rst
2

Could you please clarify what exactly is forbidden?

Using stuff from std like std::string in normal "user" code or opening std to add stuff?

If the first thing is the case why are the variables flagged but not the functions? And adding things to namespace std is AFAIK UB with the exception of template-function specializations, so maybe that would be worth a general check?

clang-tools-extra/test/clang-tidy/zircon-no-std-namespace.cpp
34

What about using int64_t and these typedefs. Are they forbidden, too?

juliehockett marked 5 inline comments as done.
juliehockett added inline comments.
clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.cpp
72

Yes, but getting the location right posed an issue there. The std token is not always at D->getLocation().

clang-tools-extra/docs/clang-tidy/checks/zircon-no-std-namespace.rst
2

Both. Documentation updated -- the uses in particular are to be flagged.

clang-tools-extra/test/clang-tidy/zircon-no-std-namespace.cpp
34

Yes, which is why that's tested. Is there an additional test case I'm missing regarding those?

JonasToth added inline comments.Oct 30 2018, 3:11 PM
clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.cpp
52

are FunctionDecl, RecordDecl (maybe better TagDecl) covered already?

72

Ok, thats unfortunate but no problem :)

clang-tools-extra/docs/ReleaseNotes.rst
176

s/its/it's/

Could std be considered code here? Not sure, but maybe using quotes is better?

clang-tools-extra/test/clang-tidy/zircon-no-std-namespace.cpp
34

Thanks for clarifying.

I think the usual problems (templates, macros) would need some test coverage.
Especially

template <std::size_t NonTypeParm>
void MyFunc();

these cases are interesting to check.

steveire added inline comments.
clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.cpp
52

Recommend extracting namespaceDecl(isStdNamespace()) to a local variable.

clang-tools-extra/test/clang-tidy/zircon-no-std-namespace.cpp
13

Are you sure it's wise to warn on every declaration inside the std namespace? Surely warning only on declarations outside it is enough.

alexfh added inline comments.Oct 31 2018, 5:32 AM
clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.cpp
30

s/its/it's/, but maybe rephrase this a bit more: ", check that the target namespace of the alias is the std namespace.".

clang-tools-extra/docs/ReleaseNotes.rst
176

Actually, "its" is correct in this context ("its use" vs "it's used").

177

I guess that you're referring here to this wording from https://fuchsia.googlesource.com/zircon/+/master/docs/cxx.md: "Zircon does not use the C++ standard library". If so, it's better to avoid using the term libc++, which is the name of one particular implementation of the C++ standard library (http://libcxx.llvm.org/docs/).

JonasToth added inline comments.Oct 31 2018, 6:41 AM
clang-tools-extra/docs/ReleaseNotes.rst
176

whupsi. sry for noise.

I am a bit confused by what this check is trying to accomplish. It seems like this is intended to catch use of anything declared within the standard library, but that includes library support things that are needed to write useful code. For instance, it seems this means users cannot use initializer lists or type traits. I'm not even certain users can overload operator new() because that uses std::size_t as an argument.

Can you expound on the requirements in a bit more detail? Is it truly "no standard library functionality at all, including things required to be supported in freestanding implementations"?

clang-tools-extra/clang-tidy/zircon/NoStdNamespaceCheck.cpp
57–60

Is the intention here to diagnose code like this?

#include <cstdlib>

int main() {
  abort(); // Diagnose this?
}
Eugene.Zelenko added inline comments.
clang-tools-extra/docs/ReleaseNotes.rst
176

Please synchronize with first statement in documentation.

juliehockett planned changes to this revision.Nov 2 2018, 12:53 PM
juliehockett marked 5 inline comments as done.

I am a bit confused by what this check is trying to accomplish. It seems like this is intended to catch use of anything declared within the standard library, but that includes library support things that are needed to write useful code. For instance, it seems this means users cannot use initializer lists or type traits. I'm not even certain users can overload operator new() because that uses std::size_t as an argument.

Can you expound on the requirements in a bit more detail? Is it truly "no standard library functionality at all, including things required to be supported in freestanding implementations"?

Yes. We're in the process of enabling the C++ standard library in the Zircon userspace code, and there is a firm requirement that no kernel code use anything in the std namespace (which declares its own implementations of things like type traits).

That said, the policy rollout has shifted a bit since I implemented this and so I'll be reworking it a bit (and also likely renaming it to zircon-kernel-no-std-namespace, so we can disable it for userspace code). Thanks all for your comments!

juliehockett abandoned this revision.Jun 28 2019, 11:23 AM