Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

Re: [perl #112786] perlbug AutoReply: build broken under clang++

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


craigberry at mac

May 6, 2012, 4:48 PM

Post #1 of 3 (56 views)
Permalink
Re: [perl #112786] perlbug AutoReply: build broken under clang++

clang++ seems to need only an extra set of parentheses to calm down and let go of its anxieties:

% git diff
diff --git a/sv.c b/sv.c
index 3ac2fd8..1713977 100644
--- a/sv.c
+++ b/sv.c
@@ -13966,7 +13966,7 @@ Perl_varname(pTHX_ const GV *const gv, const char gvtype, PADOFFSET targ,
}
}
else {
- CV * const cv = gv ? (CV *)gv : find_runcv(NULL);
+ CV * const cv = gv ? ((CV *)gv) : find_runcv(NULL);
SV *sv;
AV *av;

[snip]

IMO, something like this ought to go in for 5.16.0 because it is a build failure, and clang++ is a compiler,[1] and someone not knowing any better might try to compile Perl with it.

Those dozens or hundreds of you who actually use C++ at the day job and/or know something about C++ parsing rules may want to chime in about whether clang++ has gone slightly bonkers or is just living out its identity as its own eccentric, hypersensitive C++ self.

[1] Thanks to Apple's XCode, an increasingly ubiquitous one.


fawaka at gmail

May 7, 2012, 2:46 AM

Post #2 of 3 (50 views)
Permalink
Re: [perl #112786] perlbug AutoReply: build broken under clang++ [In reply to]

On Mon, May 7, 2012 at 1:48 AM, Craig A. Berry <craigberry [at] mac> wrote:
> Those dozens or hundreds of you who actually use C++ at the day job and/or know something about C++ parsing rules may want to chime in about whether clang++ has gone slightly bonkers or is just living out its identity as its own eccentric, hypersensitive C++ self.

I suspect it's clang++ being bonkers.

A nested name specifier is sort of C++'s equivalent of a namespace.
Such namespaces are introduced not only by the namespace keyword, but
also by types. In this case, it's struct gv that's confusing clang++.
I haven't looked up the exact rules, but I really don't think it
should be confused, it should just backtrack and interpret gv as an
unqualified name. My hunch would be that it's some kind of faulty
heuristic acting up (triggered by a colon after a valid typename).

Leon


nick at ccl4

May 8, 2012, 4:11 AM

Post #3 of 3 (49 views)
Permalink
Re: [perl #112786] perlbug AutoReply: build broken under clang++ [In reply to]

On Mon, May 07, 2012 at 11:46:56AM +0200, Leon Timmermans wrote:
> On Mon, May 7, 2012 at 1:48 AM, Craig A. Berry <craigberry [at] mac> wrote:
> > Those dozens or hundreds of you who actually use C++ at the day job and/or know something about C++ parsing rules may want to chime in about whether clang++ has gone slightly bonkers or is just living out its identity as its own eccentric, hypersensitive C++ self.
>
> I suspect it's clang++ being bonkers.

I installed clang-3.0 from macports, and its clang++ is equally bonkers.
clang-3.1 seems to be due for release in the next week or so, but I admit
that I didn't feel like pegging the CPU for the better part of another hour
to build a pre-release version just to find out if it's changed (yet).

> A nested name specifier is sort of C++'s equivalent of a namespace.
> Such namespaces are introduced not only by the namespace keyword, but
> also by types. In this case, it's struct gv that's confusing clang++.
> I haven't looked up the exact rules, but I really don't think it
> should be confused, it should just backtrack and interpret gv as an
> unqualified name. My hunch would be that it's some kind of faulty
> heuristic acting up (triggered by a colon after a valid typename).

For me, I also got 4 errors from the same part of the statement. That's
less than awesome - most unusual for clang, which raise the bar on the
standard of error messages.

Nicholas Clark

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.