This is an archive of the discontinued LLVM Phabricator instance.

Location and Range unittests for FriendDecl
ClosedPublic

Authored by nikola on May 26 2014, 2:28 AM.

Details

Reviewers
nikola
rsmith
Summary

Any other interesting scenarios to test while am at it?

Diff Detail

Event Timeline

nikola updated this revision to Diff 9796.May 26 2014, 2:28 AM
nikola retitled this revision from to Location and Range unittests for FriendDecl.
nikola updated this object.
nikola edited the test plan for this revision. (Show Details)
nikola added a reviewer: klimek.
nikola added a subscriber: Unknown Object (MLST).
klimek accepted this revision.May 26 2014, 2:38 AM
klimek edited edge metadata.

This looks like a positive step, so LG.
(I assume you have checked that at least of them fails without your patch ;)

Richard might have more ideas for corner cases (he's a master of corner cases)

This revision is now accepted and ready to land.May 26 2014, 2:38 AM
klimek added a subscriber: rsmith.May 26 2014, 2:39 AM

+richard for corner case generation

Yep, the one with friend class fails without my patch.

nikola added a comment.Jun 5 2014, 9:50 PM

Committed these tests in r210306 but I'll leave this review request open in case the following code produces something in the next week or so :)

richard_smith_engine e(beer()); // not sure if this is a proper way to seed the engine
obscure_frienddecl_distribution d(e);
d();
nikola updated this revision to Diff 10374.Jun 12 2014, 4:54 PM
nikola edited edge metadata.

Turns out we didn't have correct location and range for class template friend. The same was true for case where friend is not the first token as in Richard's inline example.

Manuel:
Are my constructor/destructor matchers good?

Richard:

  1. What's the TypeSourceInfo case in FriendDecl::getSourceRange?
  2. I couldn't find a way to hit the first call to FriendDecl::Create inside Sema::ActOnTemplatedFriendTag (some kind of explicit specialization case). I tried issuing a random diagnostic from there hoping it would break something in the test suite but it seems we don't have any coverage for this?

One comment, the rest looks fine.

include/clang/AST/DeclFriend.h
148 ↗(On Diff #10374)

This use of < is not correct (it'll do the wrong thing in the presence of macro expansion). SourceManager::isBeforeInTranslationUnit is the right way, but it's hard to get at from here. What does a friend function declaration think its LocStart is? Does that include the friend token already? Maybe you can just use that.

nikola added inline comments.Jun 30 2014, 10:52 PM
include/clang/AST/DeclFriend.h
148 ↗(On Diff #10374)

This is very unfortunate but getStartLoc depends on the range, it's whatever beginning of the range is :(

Note that we need this only for that contrived case of yours ;) where friend isn't the first token in the declaration. What's worse, having wrong range in that case or in the presence of macro expansion? Who uses macros anyway :P

I tried this but friend keyword and start of NamedDecl point to same location. Could we already be wrong in this case?

#define DECL void f();
struct A{
  friend DECL
};
nikola edited reviewers, added: rsmith; removed: klimek.Jul 14 2014, 6:29 PM
nikola removed a subscriber: rsmith.
This revision now requires review to proceed.Jul 14 2014, 6:29 PM
nikola updated this revision to Diff 11553.Jul 16 2014, 7:00 PM

This covers all test cases.

nikola accepted this revision.Jul 16 2014, 7:08 PM
nikola added a reviewer: nikola.

Committed in r213220.

This revision is now accepted and ready to land.Jul 16 2014, 7:08 PM
nikola closed this revision.Jul 22 2014, 4:57 PM