[Bug c++/24425] New: [4.0/4.1 Regression] Rejects code from kdegraphics3

[Bug c++/24425] New: [4.0/4.1 Regression] Rejects code from kdegraphics3

[rguenth at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

kdegraphics3 contains auto-generated code that fails to build with recent
4.0/4.1
while it worked at least with

g++ (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)


Testcase:

class QString;
namespace DOM {
    class __attribute__ ((visibility("default"))) DomShared {};
    class NodeImpl;
    class __attribute__ ((visibility("default"))) Node {
        Node firstChild() const;
        Node nextSibling() const;
        bool hasChildNodes ( );
        bool isNull() const { return !impl; }
        NodeImpl *impl;
    };
    class __attribute__ ((visibility("default"))) Element : public Node {};
}
namespace KSVG {
    class SVGDOMNodeBridge {};
    class SVGDOMElementBridge : public SVGDOMNodeBridge {};
    class SVGDocumentImpl;
    class SVGElementImpl : virtual public DOM::DomShared, public DOM::Element,
public SVGDOMElementBridge
    {
        SVGDocumentImpl *ownerDoc() const;
    };
    class SVGHelperImpl {
        template<class T>
        static void applyContainer(T *obj, int token, const QString &value)
        {
            SVGElementImpl *element = dynamic_cast<SVGElementImpl *>(obj);
            for(DOM::Node node = element->firstChild(); !node.isNull(); node =
node.nextSibling())
                T *cast = dynamic_cast<T
*>(element->ownerDoc()->getElementFromHandle(node));
        }
    };
}


SVGLengthImpl.min.ii: In static member function ‘static void
KSVG::SVGHelperImpl::applyContainer(T*, int, const QString&)’:
SVGLengthImpl.min.ii:28: error: invalid use of undefined type ‘struct
KSVG::SVGDocumentImpl’
SVGLengthImpl.min.ii:17: error: forward declaration of ‘struct
KSVG::SVGDocumentImpl’


-- 
           Summary: [4.0/4.1 Regression] Rejects code from kdegraphics3
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425

[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2005-10-18 10:22 -------
I guess before we treated the whole expression

 T *cast = dynamic_cast<T *>(element->ownerDoc()->getElementFromHandle(node));

as dependent on T, while afterwards we try to resolve everything for the
argument of the dynamic_cast<>.  Whether the one or the other is the correct
behavior is beyond my current knowledge.

EDG accepts the testcase in non-strict mode, but rejects it with -strict_ansi.
Maybe we can do the same with -fpermissive?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425

[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-18 12:56 -------
Reduced testcase:
class SVGDocumentImpl;
class SVGElementImpl
{
  SVGDocumentImpl *ownerDoc() const;
};
template<class T>
void applyContainer(SVGElementImpl *element)
{
  dynamic_cast<T*>(element->ownerDoc()->getElementFromHandle());
}


I don't think we should allow this at all even in premissive mode because it
does not make sense at all that the expression
"element->ownerDoc()->getElementFromHandle()" is dependent at all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425

[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3

[steven at gcc dot gnu dot org]

------- Comment #3 from steven at gcc dot gnu dot org  2005-10-18 21:30 -------
It does make sense to allow this if the (other) industry standard C++ compiler
allows this in !pedantic mode.  For backward source compatibility if nothing
else.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-18 21:30:50
               date|                            |
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425

[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2005-10-18 21:35 -------
This was caused by:
        PR c++/21592
        * pt.c (build_non_dependent_expr): Don't wrap a COMPONENT_REF
        with already looked up member functions.  Assert we're not
        returning a NON_DEPENDENT_EXPR with unknown type.
        * typeck.c (finish_class_member_access_expr):  We can get
        non-template-id-expr baselinks.  If the lookup finds a baselink,
        remember it even inside templates.

The issue here is that with -fpremissive if we change the behavior, we will
then have a rejects valid.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |trivial


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425

[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3

[mmitchel at gcc dot gnu dot org]

------- Comment #5 from mmitchel at gcc dot gnu dot org  2005-10-18 21:40 -------
This code is invalid.  (EDG rejects this code in its strictly conforming mode,
as well.)

We cannot support it without changing the meaning of conforming programs.

I don't see anything about this particular case which makes it "special"
relative to other places in which we've fixed the compiler and, as a
side-effect, made it somewhat more strict.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425