Bug 121435 - Invalid code generated for clang
Summary: Invalid code generated for clang
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Bindings (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Allan Sandfeld Jensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-16 08:41 PDT by Allan Sandfeld Jensen
Modified: 2013-09-16 11:41 PDT (History)
3 users (show)

See Also:


Attachments
Patch (1.64 KB, patch)
2013-09-16 08:43 PDT, Allan Sandfeld Jensen
andersca: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Sandfeld Jensen 2013-09-16 08:41:28 PDT
In the generation code we currently append a space to the variable $implType, but $implType is later used in compile assert to construct method names where it is assumed it does not have trailing white-space.

Since we require C++11 already, the appended space can be removed. It was only appended to avoid template<S<T>> syntax.
Comment 1 Allan Sandfeld Jensen 2013-09-16 08:43:56 PDT
Created attachment 211792 [details]
Patch
Comment 2 Anders Carlsson 2013-09-16 08:59:04 PDT
(In reply to comment #0)
> In the generation code we currently append a space to the variable $implType, but $implType is later used in compile assert to construct method names where it is assumed it does not have trailing white-space.

I don't know what you mean by "invalid code"? Invalid C++ code or invalid machine code? Why are we not seeing this on the Mac bots that already build with clang?

Can you give a more concrete example?
Comment 3 Anders Carlsson 2013-09-16 08:59:18 PDT
Comment on attachment 211792 [details]
Patch

r- for now.
Comment 4 Allan Sandfeld Jensen 2013-09-16 09:26:17 PDT
(In reply to comment #2)
> (In reply to comment #0)
> > In the generation code we currently append a space to the variable $implType, but $implType is later used in compile assert to construct method names where it is assumed it does not have trailing white-space.
> 
> I don't know what you mean by "invalid code"? Invalid C++ code or invalid machine code? Why are we not seeing this on the Mac bots that already build with clang?
> 
> Can you give a more concrete example?

COMPILE_ASSERT(__is_polymorphic(SVGPathSegListPropertyTearOff ), SVGPathSegListPropertyTearOff _is_not_polymorphic);

Notice the space between SVGPathSegListPropertyTearOff and _is_not_polymorphic.
Comment 5 Anders Carlsson 2013-09-16 10:21:39 PDT
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #0)
> > > In the generation code we currently append a space to the variable $implType, but $implType is later used in compile assert to construct method names where it is assumed it does not have trailing white-space.
> > 
> > I don't know what you mean by "invalid code"? Invalid C++ code or invalid machine code? Why are we not seeing this on the Mac bots that already build with clang?
> > 
> > Can you give a more concrete example?
> 
> COMPILE_ASSERT(__is_polymorphic(SVGPathSegListPropertyTearOff ), SVGPathSegListPropertyTearOff _is_not_polymorphic);
> 
> Notice the space between SVGPathSegListPropertyTearOff and _is_not_polymorphic.

I still don’t see what the problem is - COMPILE_ASSERT is being #defined as static_assert, so the above assertion just turns into:

static_assert((__is_polymorphic(SVGPathSegListPropertyTearOff )), "SVGPathSegListPropertyTearOff _is_not_polymorphic");

I think the above compile assertion should just be converted into a static_assert that uses std::is_polymorphic.
Comment 6 Allan Sandfeld Jensen 2013-09-16 11:33:11 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > (In reply to comment #0)
> > > > In the generation code we currently append a space to the variable $implType, but $implType is later used in compile assert to construct method names where it is assumed it does not have trailing white-space.
> > > 
> > > I don't know what you mean by "invalid code"? Invalid C++ code or invalid machine code? Why are we not seeing this on the Mac bots that already build with clang?
> > > 
> > > Can you give a more concrete example?
> > 
> > COMPILE_ASSERT(__is_polymorphic(SVGPathSegListPropertyTearOff ), SVGPathSegListPropertyTearOff _is_not_polymorphic);
> > 
> > Notice the space between SVGPathSegListPropertyTearOff and _is_not_polymorphic.
> 
> I still don’t see what the problem is - COMPILE_ASSERT is being #defined as static_assert, so the above assertion just turns into:
> 
> static_assert((__is_polymorphic(SVGPathSegListPropertyTearOff )), "SVGPathSegListPropertyTearOff _is_not_polymorphic");
> 
> I think the above compile assertion should just be converted into a static_assert that uses std::is_polymorphic.

Unless you use clang 3.0 is which case it becomes  

typedef int dummySVGPathSegListPropertyTearOff _is_not_polymorphic [(exp) ? 1 : -1]
Comment 7 Allan Sandfeld Jensen 2013-09-16 11:34:49 PDT
Apparently only triggered with clang versions not supported in trunk. Sorry.
Comment 8 Anders Carlsson 2013-09-16 11:41:34 PDT
(In reply to comment #7)
> Apparently only triggered with clang versions not supported in trunk. Sorry.

Yeah in trunk you would have gotten a compile error due to:

#if !COMPILER_SUPPORTS(CXX_STATIC_ASSERT)
#error "Please use a compiler that supports C++11 static_assert."
#endif