This is an archive of the discontinued LLVM Phabricator instance.

Add Subjects to NoDebugAttr [NFC]
ClosedPublic

Authored by probinson on Apr 28 2016, 2:10 PM.

Details

Summary

The 'nodebug' attribute had hand-coded constraints; replace those with a Subjects line in Attr.td.
Also add a missing test to verify the attribute is okay on an Objective-C method.

Diff Detail

Repository
rL LLVM

Event Timeline

probinson updated this revision to Diff 55482.Apr 28 2016, 2:10 PM
probinson retitled this revision from to Add Subjects to NoDebugAttr [NFC].
probinson updated this object.
probinson added a reviewer: aaron.ballman.
probinson added a subscriber: cfe-commits.

Generally tests test something other than "this program doesn't crash" - should it test that we apply the attribute correctly? (either via ast dump, or checking the resulting DWARF doesn't have debug info on the relevant entity)

Or is this not actually a new/separate codepath? In which case do we really need the test?

It's a –verify test which is about diagnostics, rather than not-crashing. It parallels line 3 of Sema/attr-nodebug.c, which verifies the attribute can be applied to a function. Without this test, you could remove "ObjCMethod" from the Subjects line and no test would fail. I put "ObjCMethod" on the Subjects line because the hand-coded condition used "isFunctionOrMethod" which permits Objective-C methods. The new test passes with old and new compilers, demonstrating the NFC claim.

Now, if we decide the 'nodebug' attribute should not apply to Objective-C, that's fine with me, in which case the new test should verify that a diagnostic *is* produced.

I am admittedly clueless about Objective-C, are they handled differently from other functions by the time we get to CGDebugInfo? If there's another path I should tweak, I'd like to know about it.
Thanks,
--paulr

From: David Blaikie [mailto:dblaikie@gmail.com]
Sent: Thursday, April 28, 2016 4:26 PM
To: reviews+D19689+public+514682b5314c52ad@reviews.llvm.org; Robinson, Paul
Cc: Aaron Ballman; cfe-commits
Subject: Re: [PATCH] D19689: Add Subjects to NoDebugAttr [NFC]

LGTM

aaron.ballman accepted this revision.Apr 29 2016, 5:57 AM
aaron.ballman edited edge metadata.

This turns out to be a bit of a mess: Alias and NoDebug use the same diagnostic kind text, neither of which match the actual subject list. Alias doesn't appertain to an obj-c method or property. NoDebug doesn't appertain to an obj-c property. The diagnostic text for that diagnostic kind doesn't match the subject list it is describing in either case. And the diagnostic text talks about "global variables" when what it really means are "variables that have global *storage*" and so static storage duration is a bit more accurate than "global variable" which implies that the following should diagnose:

void f() {
  static int i __attribute__((nodebug));
}

I have a WIP patch (D18768) that will hopefully make this situation better. Your current changes will add a bit of overhead to my refactoring, but it's a drop in the bucket compared to the other diagnostic wording changes, so I'm not overly concerned. I think the patch LGTM despite my comments.

include/clang/Basic/Attr.td
977 ↗(On Diff #55482)

It's really strange that the diagnostic kind is ExpectedFunctionGlobalVarMethodOrProperty but the subject list does not have objective-c properties. It's even more strange that this diagnostic kind corresponds to the diagnostic text "functions and global variables" without mention of objective-c methods or properties. I see that the Alias attribute suffers from this same discombobulation.

test/Sema/attr-nodebug.c
6 ↗(On Diff #55482)

Global variables is a misnomer though since this really applies to variables with static storage duration (including local variables).

This revision is now accepted and ready to land.Apr 29 2016, 5:57 AM

I'll proceed from here without doing anything about the inconsistencies, because this particular one should go away and you're already doing something about the rest of it.

include/clang/Basic/Attr.td
977 ↗(On Diff #55482)

I agree, but I didn't want to do anything about it because my next step is to replace GlobalVar with Var in the SubjectList, and therefore change the diagnostic enum to something else, making the inconsistency moot (at least for this attribute).

This revision was automatically updated to reflect the committed changes.