Closed Bug 983513 Opened 6 years ago Closed 6 years ago
.cpp:2552:48: error: reference to ‘Null Ptr’ is ambiguous (--disable-ion)
In file included from js/src/Unified_cpp_js_src2.cpp:197: In file included from js/src/jsobj.cpp:61: js/src/vm/Runtime-inl.h:65:19: warning: unused variable 'obj' [-Wunused-variable] JSObject *obj = js::gc::AllocateObjectForCacheHit<allowGC>(cx, entry... ^ In file included from js/src/Unified_cpp_js_src2.cpp:197: js/src/jsobj.cpp:2552:48: error: reference to 'NullPtr' is ambiguous RootedFunction fun(cx, NewFunction(cx, NullPtr(), constructor, nargs, ^ dist/include/js/RootingAPI.h:134:8: note: candidate found by name lookup is 'js::NullPtr' struct NullPtr ^ dist/include/js/RootingAPI.h:169:22: note: candidate found by name lookup is 'JS::NullPtr' struct JS_PUBLIC_API(NullPtr) ^ js/src/jstypes.h:73:41: note: expanded from macro 'JS_PUBLIC_API' # define JS_PUBLIC_API(t) MOZ_EXPORT t ^ In file included from js/src/Unified_cpp_js_src2.cpp:197: js/src/jsobj.cpp:4318:19: warning: unused variable 'script' [-Wunused-variable] JSScript *script = cx->currentScript(&pc); ^ 2 warnings and 1 error generated. gmake: *** [Unified_cpp_js_src2.o] Error 1 bisect culprit - https://hg.mozilla.org/mozilla-central/rev/6635d1edc749 http://mozillaproject.osuosl.org:8010/builders/runtests/builds/1107/steps/shell/logs/stdio http://buildbot.rhaalovely.net/builders/mozilla-central-sparc64/builds/730/steps/build/logs/stdio
This one prevent me to build as well.
Attachment #8391934 - Flags: review?(nicolas.b.pierron)
6 years ago
Attachment #8391934 - Attachment is patch: true
Attachment #8391934 - Flags: review?(nicolas.b.pierron) → review+
(In reply to Jan Beich from comment #0) > dist/include/js/RootingAPI.h:134:8: note: candidate found by name lookup is > 'js::NullPtr' > struct NullPtr > ^ > dist/include/js/RootingAPI.h:169:22: note: candidate found by name lookup is > 'JS::NullPtr' > struct JS_PUBLIC_API(NullPtr) How should we solve this ambiguity? As soon as we fix it, we should revert Vivien's changes.
Assignee: nobody → 21
Status: NEW → ASSIGNED
That is an issue with unified builds, not with NullPtr. We wanted the same name inside and outside the engine, but we did not want to eat the performance overhead of a GOT lookup inside the engine on Windows. For this symbol the namespace must be considered part of the name in contexts where the compiler cannot derive it automatically. I think the above patch is the right solution here.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.