675905 - Solaris(sparc)/SunStudio12.2 build error on "jsonparser.cpp"

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Peter Müller]

User Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.19) Gecko/20110502 Lightning/1.0b2pre SeaMonkey/2.0.14
Build ID: 20110502133110

Steps to reproduce:

Compiling seamonkey-2.2.source on SolarisSparc with current SunStudio compiler (V12.2) ...


Actual results:

... fails on "comm-release/mozilla/js/src/jsonparser.cpp" with following error massage:

"comm-release/mozilla/js/src/jsonparser.cpp", line 64: Error: Error: JSONSourceParser::StringType is not accessible from file level.

Comment 1

[Philip Chee]

I'm going to move this bug to the js-engine component for triage.

Comment 2

[Jeff Walden [:Waldo]]

I'd bet moving the enum StringType in jsonparser.h to a public: section of the JSONParser class in jsonparser.h fixes this, but seeing as I have no way to test on Solaris and have other things needing doing, I'll leave actual investigation to someone else.

The other possibility is that the Solaris compiler implements the spec correctly, and its error is accurate.  But given no other compiler complained, I suspect that's less likely.  Luke, is it legal to use a type which is marked private in the way demonstrated below, for the Foo enum type?

  class A {
    private:
      enum Foo { x, y };
      template<Foo f> int m();
  };
  
  template<A::Foo f> int
  A::m()
  {
    return f;
  }

The Solaris compiler's complaining that using A::Foo like that is bad, at file scope, because it's private to A.  But if it's used for a method within A, I'd think that was perfectly fine.

Comment 3

[Luke Wagner [:luke]]

These scoping issues always confound and frustrate me; I'm also not hip enough with the scoping part of the standard to quickly look it up.

Comment 4

[Jeff Walden [:Waldo]]

I can't stand being daunted by a spec, so I investigated.  :-)  I think 11 Member Access Control paragraph 5 says that the Solaris compiler is buggy and the other compilers are not, when it says:

  The access control for names used in the definition of a class member that
  appears outside of the member’s class definition is done as if the entire
  member definition appeared in the scope of the member’s class.

So A::m's definition above would have to be access-controlled as if it appeared inside class A directly, and there it definitely should be able to access A::Foo, so the example, and JSONParser itself, are well-formed C++.

Comment 5

[Ginn Chen]

This is a bug of Solaris Studio.
I've filed it as CR 7068692.

You can move StringType to public to get around it.

Comment 6

[Peter Müller]

(In reply to comment #2)
> I'd bet moving the enum StringType in jsonparser.h to a public: section of
> the JSONParser class in jsonparser.h fixes this, but seeing as I have no way
> to test on Solaris and have other things needing doing, I'll leave actual
> investigation to someone else.

Yes, I can confirm this:

*** jsonparser.h.orig   Wed Jul  6 10:49:14 2011
--- jsonparser.h        Wed Aug  3 11:53:39 2011
***************
*** 159,164 ****
--- 159,165 ----
          return Number;
      }
  
+   public:
      enum StringType { PropertyName, LiteralValue };
      template<StringType ST> Token readString();

The compiler is happy now. BTW the problem still exists with
SolarisStudio (aka SunStudio) 12.3-beta.

Comment 7

[Peter Müller]

(In reply to comment #5)
> This is a bug of Solaris Studio.
> I've filed it as CR 7068692.
> 
> You can move StringType to public to get around it.

Thank you: a small step forward building SeaMonkey 2.2 on SolarisSparc.

Comment 8

[Peter Müller]

(In reply to comment #5)
> This is a bug of Solaris Studio.
> I've filed it as CR 7068692.
> 
> You can move StringType to public to get around it.

Thank you: a small step forward building SeaMonkey 2.2 on SolarisSparc.

Comment 9

[Jan de Mooij [:jandem]]

Assuming this works now after two years. Please file a new bug if it still doesn't work.