This is an archive of the discontinued LLVM Phabricator instance.

Fix for PR18393 - emit error when abstract type is returned or taken by value
Needs ReviewPublic

Authored by matekm on Sep 19 2014, 5:04 AM.

Details

Reviewers
rsmith
Summary

Hi,

Attached patch contains the implementation of a fix for PR18393[1]. According to standard "An abstract class shall not be used as a parameter type, as a function return type, or as the type of an explicit conversion" (class.abstract $10.4.3).

Currently, checking if type isn't abstract class is done when method is defined, but I don't see any reason why clang shouldn't do it as early as possible, in this case, when function/method is declared. Test also attached.

Please, review and provide feedback or propose additional tests.

Thanks in advance
Robert Matusewicz

Diff Detail

Event Timeline

matekm updated this revision to Diff 13862.Sep 19 2014, 5:04 AM
matekm retitled this revision from to Fix for PR18393 - emit error when abstract type is returned or taken by value.
matekm updated this object.
matekm edited the test plan for this revision. (Show Details)
matekm added a reviewer: rsmith.
matekm added a subscriber: Unknown Object (MLST).
rsmith edited edge metadata.Sep 25 2014, 5:08 PM

Clang doesn't do this immediately because that's not correct:

struct S {
  S f();
  virtual void g() = 0;
};

We can't tell that we need to diagnose f until we reach the declaration
of g.

In D5409#4, @rsmith wrote:

Clang doesn't do this immediately because that's not correct:

struct S {
  S f();
  virtual void g() = 0;
};

We can't tell that we need to diagnose f until we reach the declaration
of g.

Hi,

actually after applying my patch the case you presented is handled correctly. The problematic case is this one:

struct AbstractClass;

struct S {
  AbstractClass f();
};

struct AbstracClass {
   virtual void g() = 0;
};

This isn't catched by my patch. I will dig deeper to check where is the problem

Any updates on this?