The compiler is hitting a syntax error.

I assume MOZ_FINAL is a macro that gets expanded to something?

Please preprocess the file using -E -P andshow uswhat the source looks like afterpreprocessing.

thanks
Judy

I am able to compile theFirefox JS engine only. which module are you building? are you using VS2010? how do you change the config to use icl?

Jennifer

Yes please preprocess SourceSurfaceD2DTarget.cpp (just take the compilation command line shown in your log above and add -P to it). This should create a preprocessed file called SourceSurfaceD2DTarget.i. Look in that file for the line that gets the compilation error.

From what I found here:

http://whereswalden.com/2011/11/26/introducing-moz_final-prevent-inheriting-from-a-class-or-prevent-overriding-a-virtual-function/

It looks like the MOZ_FINAL macro uses the C++11 keyword "final" which is not yet implemented in our 12.1 compiler (or by MSVC++ 2010). So wherever that macro is beingdefined in the libraryit should not be expanded to anything.

If that really is a problem then adding -DMOZ_FINAL= to the command line may help.

thanks,
Judy

I'm unable to see anything in the .i file. Is it empty? May be it's too big.

What I was asking you to do was toadd -P to all your normal compilationoptions -- not toreplace all your options with just that one.

So the command line should look like:

icl (all your normal compilation options here) -P SourceSurfaceD2DTarget.cpp

then we canlook at the resulting .i file andsee the line (after macro expansion) that's causing the compilation error.

If you're using 13.0 then you must be in the beta program so perhaps you should just file a bug
report through the normal channels.

thanks,
Judy

Hello,

there's no progress on this thread and so I took a look.

The preprocessed output does not fit to the error displayed:
On the command-line the error occurs for class ExpirationTrackerObserver but this one does not exist in the preprocessed output.

Are you sure you executed the very same icl command when creating the preprocessed output?

Best regards,

Georg Zitzlsberger

Hi everybody,

It would be very useful if somebody will attach nsExpirationTracker.h, gfxFont.h and a header file with MOZ_FINAL macro declaration.

I think the problem could be reproduced in a small test-case.

Best regards,
Sergey

there's no progress on this thread and so I took a look.
...

Hi Georg, Did you see a couple of comments about 'MOZ_FINAL' macroat:

https://bugzilla.mozilla.org/show_bug.cgi?id=704687
https://bugzilla.mozilla.org/show_bug.cgi?id=704127 [Edited] Added

Please take a look.

Best regards,
Sergey

[Edited] Added: A google search with 'MOZ_FINAL' returns 1,370 results!

And one more to look at:

https://bug704127.bugzilla.mozilla.org/attachment.cgi?id=575855

Herearetwo very interesting pieces of codes from a patch:

[ 1 ]
...
#elif defined(_MSC_VER)
# if _MSC_VER >= 1400 [SergeyK] For VS2005, VS2008, etc
# define MOZ_HAVE_CXX11_OVERRIDE
+ /* MSVC currently spells "final" as "sealed". */
+# define MOZ_HAVE_CXX11_FINAL sealed
# endif
#endif
...

[ 2 ]
...
+/*
+ * MOZ_FINAL indicates that some functionality cannot be overridden through
+ * inheritance. It can be used to annotate either classes/structs or virtual
+ * member functions.
+ *
+ * To annotate a class/struct with MOZ_FINAL, place MOZ_FINAL immediately after
+ * the name of the class, before the list of classes from which it derives (if
+ * any) and before its opening brace. MOZ_FINAL must not be used to annotate
+ * unnamed classes or structs. (With some compilers, and with C++11 proper, the
+ * underlying expansion is ambiguous with specifying a class name.)
+ *
+ * class Base MOZ_FINAL
+ * {
+ * public:
+ * Base();
+ * ~Base();
+ * virtual void f() { }
+ * };
+ * // This will be an error in some compilers:
+ * class Derived : public Base
+ * {
+ * public:
+ * ~Derived() { }
+ * };
+ *
+ * One particularly common reason to specify MOZ_FINAL upon a class is to tell
+ * the compiler that it's not dangerous for it to have a non-virtual destructor
+ * yet have one or more virtual functions, silencing the warning it might emit
+ * in this case. Suppose Base above weren't annotated with MOZ_FINAL. Because
+ * ~Base() is non-virtual, an attempt to delete a Derived* through a Base*
+ * wouldn't call ~Derived(), so any cleanup ~Derived() might do wouldn't happen.
+ * (Formally C++ says behavior is undefined, but compilers will likely just call
+ * ~Base() and not ~Derived().) Specifying MOZ_FINAL tells the compiler that
+ * it's safe for the destructor to be non-virtual.
+ *
+ * In compilers implementing final controls, it is an error to inherit from a
+ * class annotated with MOZ_FINAL. In other compilers it serves only as
+ * documentation.
+ *
+ * To annotate a virtual member function with MOZ_FINAL, place MOZ_FINAL
+ * immediately before the ';' terminating the member function's declaration, or
+ * before '= 0;' if the member function is pure. If the member function is
+ * defined in the class definition, it should appear before the opening brace of
+ * the function body. (This placement is identical to that for MOZ_OVERRIDE.
+ * If both are used, they should appear in the order 'MOZ_FINAL MOZ_OVERRIDE'
+ * for consistency.)
+ *
+ * class Base
+ * {
+ * public:
+ * virtual void f() MOZ_FINAL;
+ * };
+ * class Derived
+ * {
+ * public:
+ * // This will be an error in some compilers:
+ * virtual void f();
+ * };
+ *
+ * In compilers implementing final controls, it is an error for a derived class
+ * to override a method annotated with MOZ_FINAL. In other compilers it serves
+ * only as documentation.
+ */
+#if defined(MOZ_HAVE_CXX11_FINAL)
+# define MOZ_FINAL MOZ_HAVE_CXX11_FINAL
+#else
+# define MOZ_FINAL /* no support */
+#endif
+
...

and I wonder if:

#undef MOZ_HAVE_CXX11_FINAL

at some header will help. However I'm not sure because the 'sealed' keyword has to be supported, or a declaration:

...
#if< Intel C++ compiler >
#define MOZ_HAVE_CXX11_FINAL
#endif
...

is not defined?

Hello all,

sometimes its hard to see the forest for the trees... I missed that MOZ_FINAL was defined in the command line:

The problem: The macro MOZ_FINAL is only defined but not initialized.
Solution: Use -DMOZ_FINAL="" to initialize it.

Btw.: Sergey, _MSC_VER is implicitly set by our compilers. There's no need for special handling here.

Best regards,

Georg Zitzlsberger

Hi Georg, It would be nice togeta responsefrom 'AlexBoy94'.

Also, I was thinking about your great discovery and I think a test-case to reproduce the problem could look like:

Note:Template-based pseudo-codes / I didn't try to compile / Non-Template-based version also could be considered

...
#define _CLASS_FINAL
//#define _CLASS_FINAL sealed // For C++ compiler A
//#define _CLASS_FINAL final// For C++ compiler B
//#define _CLASS_FINAL abcdefgh // To breakC++compilers A and B

//#undef _CLASS_FINAL

template < class T > class TTestClassA
{
public:
TTestClassA(){};
~TTestClassA(){};
};

template < class T > class TTestClassB _CLASS_FINAL : publicTTestClassA
{
public:
TTestClassB(){};
~TTestClassB(){};
};
...
void main( void )
{
TTestClassB< int > tcB;
}
...

What do you think?

Best regards,
Sergey

Intel C++ compiler could set it but I don't think that itchanges it from a default value defined by a Visual Studio.

- Let's assume that Intel C++ compiler was installed with Visual Studio 2008 Professional Edition
- In that case _MSC_VER has to beequal to 1500
- If Intel C++ compiler will set a different value it could create a "chaos" in some headers ( Platform SDK, TBB, etc )

Here are two exampleswhen TBB uses _MSC_VER macro:

< TBB - concurent_vector.h >

...
#if _MSC_VER==1500 && !__INTEL_COMPILER
// VS2008/VC9 seems to have an issue; limits pull in math.h
#pragma warning( push )
#pragma warning( disable: 4985 )
#endif
...

< TBB - scalable_allocator_vector.h >

...
#if _MSC_VER >= 1400
#define __TBB_EXPORTED_FUNC __cdecl
#else
#define __TBB_EXPORTED_FUNC
#endif
...

Thereisfreedom with Intel specific macros, like__INTEL_COMPILER, etc.

...
- If Intel C++ compiler will set a different value it could create a "chaos" in some headers ( Platform SDK, TBB, etc )
...

That is why on our project there is ablock of codes that does averification for Visual Studio version:

...
#if defined ( _WIN32_MSC )
#define _CPPCOMPILER_VER( _MSC_VER )
#endif
...
#if _CPPCOMPILER_VER < 1200
#define _SCALIB_CPPCOMPILER_VER"5.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual C++ v5.0 is NOT supported ***" )
#endif

#if _CPPCOMPILER_VER == 1200
#define _SCALIB_CPPCOMPILER_VER"6.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 98 ***" )
#endif

#if _CPPCOMPILER_VER == 1300
#define _SCALIB_CPPCOMPILER_VER"7.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2003 ***" )
#endif

#if _CPPCOMPILER_VER == 1310
#define _SCALIB_CPPCOMPILER_VER"7.1"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2003 ***" )
#endif

#if _CPPCOMPILER_VER == 1400
#define _SCALIB_CPPCOMPILER_VER"8.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2005 ***" )
#endif

#if _CPPCOMPILER_VER == 1500
#define _SCALIB_CPPCOMPILER_VER"9.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2008 ***" )
#endif

#if _CPPCOMPILER_VER == 1600
#define _SCALIB_CPPCOMPILER_VER"10.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2010 ***" )
#endif
...

So, if Intel C++ compiler would changea default ( correct )value of _MSC_VER macro a Software Developer woulddetect it during compilation.

An output looks like:

------ Build started: Project: ScaLibTestApp, Configuration: Debug Win32 ------
Compiling...
Stdphf.cpp
*** ScaLib Message: Compiling with Visual Studio 2008 ***
...