js/src fails to build with -std=c++11

RESOLVED DUPLICATE of bug 877937

Status

()

Core
JavaScript Engine
RESOLVED DUPLICATE of bug 877937
5 years ago
5 years ago

People

(Reporter: Jan Beich, Unassigned)

Tracking

Trunk
All
FreeBSD
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
I'm using clang32/libc++ and it seems to be stricter than g++48/libstdc++.

  js/src/frontend/ParseMaps.cpp:137:16: error: explicit instantiation of
	'js::frontend::AtomDecls' must occur in namespace 'frontend'
  template class AtomDecls<FullParseHandler>;
		 ^
  ../../../js/src/frontend/ParseMaps.h:386:7: note: explicit instantiation refers here
  class AtomDecls
	^
  js/src/frontend/ParseMaps.cpp:138:16: error: explicit instantiation of
	'js::frontend::AtomDecls' must occur in namespace 'frontend'
  template class AtomDecls<SyntaxParseHandler>;
		 ^
  ../../../js/src/frontend/ParseMaps.h:386:7: note: explicit instantiation refers here
  class AtomDecls
	^
  2 errors generated.
Are you adding -std=c++11 to CXXFLAGS or something?  I imagine this sort of addition to CXXFLAGS or to CXX is somewhat low on the things-to-support totem.  :-)  It's a pretty fundamental addition -- I doubt we want this configurable.

That said.  If we care, the spot-fix is easy enough, and probably desirable regardless of -std=... supportedness or not.  I imagine these things will keep occasionally breaking from unwitting changes, unless SpiderMonkey converts to -std=gnu++0x.  We eschewed that for a long time in the interests of C compatibility (C++11's standard headers don't always play well with C's standard headers).  But C compatibility is no longer an issue, so we might be able to follow up on this now.  Any chance you might be able to do that?
(Reporter)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 877937
You need to log in before you can comment on or make changes to this bug.