This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] safety-no-assembler
ClosedPublic

Authored by jbcoe on Jan 29 2017, 4:05 PM.

Details

Diff Detail

Repository
rL LLVM

Event Timeline

jbcoe created this revision.Jan 29 2017, 4:05 PM
Eugene.Zelenko added inline comments.
clang-tools-extra/docs/ReleaseNotes.rst
60 ↗(On Diff #86234)

Please take look on Release Notes format in previous releases branches (3.9 and 40).

clang-tools-extra/docs/clang-tidy/checks/safety-no-assembler.rst
9 ↗(On Diff #86234)

Link to particular standard will be helpful.

Eugene.Zelenko set the repository for this revision to rL LLVM.
jbcoe updated this revision to Diff 86289.Jan 30 2017, 8:07 AM

Add link to HIC++ website and fix release notes.

Standard you linked mentions portability as the reason inline assembler should be avoided. Should it really be named 'safety'?

jbcoe added a comment.Feb 3 2017, 1:46 PM

High Integrity C++ is often used as a standard for safety-critical systems. High Integrity C++ requires no assembler due to portability issues. Not my choice of wording.
I plan to implement more of the High Integrity C++ checks, some of which are more obviously safety-related.

jbcoe marked 2 inline comments as done.Feb 3 2017, 1:46 PM
idlecode added inline comments.Feb 4 2017, 2:17 AM
clang-tools-extra/docs/clang-tidy/checks/list.rst
156 ↗(On Diff #86289)

safety-no-vector-bool seems to belong to the other patch.

clang-tools-extra/test/clang-tidy/safety-no-assembler.cpp
2 ↗(On Diff #86289)

Maybe this check should handle FileScopeAsmDecl and AsmLabelAttr too?

__asm__(".symver foo, bar@v");
static int s asm("spam");
jbcoe planned changes to this revision.Feb 4 2017, 2:43 AM
jbcoe added inline comments.
clang-tools-extra/test/clang-tidy/safety-no-assembler.cpp
2 ↗(On Diff #86289)

Agreed.

aaron.ballman added inline comments.Feb 5 2017, 8:52 AM
clang-tools-extra/clang-tidy/safety/NoAssemblerCheck.cpp
32 ↗(On Diff #86289)

The diagnostic text doesn't help the user to understand why the code is being diagnosed. Also, does printing the source text add any clarity? The diagnostic already appears on the line in which the assembly statement appears, and since this is a statement (rather than an expression), it seems unlikely to be useful to repeat that text.

alexfh edited edge metadata.Feb 6 2017, 12:31 AM

I wonder whether there's a compiler diagnostic for this purpose. Compiler diagnostics are more efficient at reaching users and should be preferred where they are appropriate (this seems like one of such cases).

jbcoe updated this revision to Diff 87207.Feb 6 2017, 2:53 AM
jbcoe marked an inline comment as done.

Improve diagnostic message. Find other sorts of inline assembler. Minor fixes for other review comments.

jbcoe marked an inline comment as done.Feb 6 2017, 2:54 AM
jbcoe added inline comments.
clang-tools-extra/clang-tidy/safety/NoAssemblerCheck.cpp
32 ↗(On Diff #86289)

Agreed. Fixed.

clang-tools-extra/docs/clang-tidy/checks/list.rst
156 ↗(On Diff #86289)

Well spotted. Thought I'd got rid of all of those.

out of curiousity:
i would like to contribute to the safety module as well. but currently there is no starting point in master. is there a way to get some code that i can start with? I think the module file where the registration happens would be enough.

this is not specifically patch related, but dunno where to ask else.

e.g. could it be possible to commit the std::vector<bool> thing, even though temlate parameters dont work right now. this could be added as a known limitation.

jbcoe added a comment.Feb 6 2017, 3:03 AM

@JonasToth My main intention with this patch is to provide such a starting point. A few people have mentioned that they'd be keen to contribute checks.

jbcoe added a comment.Feb 6 2017, 3:40 AM

@alexfh Can we defer moving this to a compiler diagnostic? I'm keen to get a target in place for people to write more safety checks.

@alexfh Can we defer moving this to a compiler diagnostic? I'm keen to get a target in place for people to write more safety checks.

+1 from me :)
and assembler might be bad style, but is it worth a warning? I think people writing assembly in their code wouldnt be amused and turn it off anyway, since they believe its necessary and worth it.

LGTM. HIC++ Standard seems worth implementing.

jbcoe marked 2 inline comments as done.Feb 6 2017, 9:21 AM
aaron.ballman edited edge metadata.Feb 6 2017, 9:24 AM

I wonder whether there's a compiler diagnostic for this purpose. Compiler diagnostics are more efficient at reaching users and should be preferred where they are appropriate (this seems like one of such cases).

I don't think a compiler diagnostic would be appropriate for this. It would be incredibly chatty for people who do need to use the assembler.

jbcoe added a comment.Feb 6 2017, 11:32 AM

@idlecode please can you approve if it LGTY?

idlecode accepted this revision.Feb 6 2017, 12:08 PM

Sure, but I don't have commit rights so someone else have to push it :)

This revision is now accepted and ready to land.Feb 6 2017, 12:08 PM
aaron.ballman added inline comments.Feb 6 2017, 12:20 PM
clang-tools-extra/clang-tidy/safety/NoAssemblerCheck.cpp
13 ↗(On Diff #87207)

Is this include needed?

36 ↗(On Diff #87207)

No need for this to be an Optional, is there?

Eugene.Zelenko added inline comments.Feb 6 2017, 1:15 PM
clang-tools-extra/clang-tidy/safety/NoAssemblerCheck.cpp
13 ↗(On Diff #87207)

Will be good idea to run Include What You Use.

This revision was automatically updated to reflect the committed changes.

There were review comments still outstanding when you commit the patch. Can you please address those post-commit?

jbcoe added a comment.Feb 6 2017, 10:23 PM

@aaron.ballman I will address post-approval comments post-commit.

jbcoe marked an inline comment as done.Feb 6 2017, 10:33 PM
jbcoe added inline comments.
clang-tools-extra/clang-tidy/safety/NoAssemblerCheck.cpp
13 ↗(On Diff #87207)

Fixed unnecessary include.

36 ↗(On Diff #87207)

I think optional makes intent clearer but am used to dealing with immutable objects.
I've changed the code to just use SourceLocation.