Closed Bug 1637199 Opened 2 months ago Closed 2 months ago

Build failure due to #include <version> picking up js/src/new-regexp/VERSION on macOS (unknown type name 'Imported', expected unqualified-id)

Categories

(Firefox Build System :: General, defect)

defect

Tracking

(firefox78 fixed)

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: kats, Assigned: iain)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

I just updated my local checkout on macOS from hg rev 19e273db80195cc5de59647fcaf16bafad9bbcce to hg rev 1706d4d54ec68fae1280305b70a02cb24c16ff68 and started getting this build error:

 9:38.12    Compiling webrender_api v0.61.0 (/Users/kats/zspace/gecko-mac/gfx/wr/webrender_api)
10:14.17    Compiling style v0.0.1 (/Users/kats/zspace/gecko-mac/servo/components/style)
11:06.85 js/src/wasm
12:39.40    Compiling webrender v0.61.0 (/Users/kats/zspace/gecko-mac/gfx/wr/webrender)
12:39.49 js/src/new-regexp
12:43.40 In file included from /Users/kats/zspace/gecko-mac/js/src/new-regexp/property-sequences.cc:7:
12:43.40 In file included from /Users/kats/zspace/gecko-mac/js/src/new-regexp/property-sequences.h:10:
12:43.40 In file included from /Users/kats/zspace/gecko-mac/js/src/new-regexp/regexp-shim.h:14:
12:43.40 In file included from /Users/kats/zspace/gecko-mac/obj-host-debugopt/dist/include/mozilla/Assertions.h:53:
12:43.40 In file included from /Users/kats/.mozbuild/clang/bin/../include/c++/v1/stdlib.h:100:
12:43.40 In file included from /Users/kats/.mozbuild/clang/bin/../include/c++/v1/math.h:311:
12:43.40 In file included from /Users/kats/.mozbuild/clang/bin/../include/c++/v1/type_traits:417:
12:43.40 In file included from /Users/kats/.mozbuild/clang/bin/../include/c++/v1/cstddef:37:
12:43.40 /Users/kats/zspace/gecko-mac/js/src/new-regexp/version:1:1: error: unknown type name 'Imported'
12:43.40 Imported using import-irregexp.py from:
12:43.40 ^
12:43.40 /Users/kats/zspace/gecko-mac/js/src/new-regexp/version:1:10: error: expected unqualified-id
12:43.40 Imported using import-irregexp.py from:
12:43.40          ^

I'm on a case-insensitive file system, and there's a VERSION file in js/src/new-regexp/ that's been there for a while. But now for some reason the #include <version> in the std cstddef header is picking it up, causing a build error. Fun!

Probably a regression from bug 1634135 although I haven't confirmed.

The mozconfig I'm using can be seen at https://github.com/staktrace/moz-scripts/blob/3de933b74c21e4cb0c1a7a879dbbcbe58ce38ea2/mozconfig.Darwin-host-debugopt

Running ./mach build -j1 --verbose produces this as the failing command:

/usr/local/bin/ccache /Users/kats/.mozbuild/clang/bin/clang++ -isysroot /Users/kats/zspace/MacOSX-SDKs/MacOSX10.11.sdk -isysroot /Users/kats/zspace/MacOSX-SDKs/MacOSX10.11.sdk -std=gnu++17 -o property-sequences.o -c  -fvisibility=hidden -fvisibility-inlines-hidden -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -ftrivial-auto-var-init=pattern -DDEBUG=1 -DWASM_SUPPORTS_HUGE_MEMORY -DJS_CACHEIR_SPEW -DJS_STRUCTURED_SPEW -DJS_HAS_CTYPES -DFFI_BUILDING -DEXPORT_JS_API -DMOZ_HAS_MOZGLUE -I/Users/kats/zspace/gecko-mac/js/src/new-regexp -I/Users/kats/zspace/gecko-mac/obj-host-debugopt/js/src/new-regexp -I/Users/kats/zspace/gecko-mac/obj-host-debugopt/js/src -I/Users/kats/zspace/gecko-mac/js/src -I/Users/kats/zspace/gecko-mac/obj-host-debugopt/dist/include -I/Users/kats/zspace/gecko-mac/obj-host-debugopt/dist/include/nspr -fPIC -DMOZILLA_CLIENT -include /Users/kats/zspace/gecko-mac/obj-host-debugopt/js/src/js-confdefs.h -Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Werror=non-literal-null-conversion -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-noexcept-type -Wno-unknown-warning-option -fno-sized-deallocation -fno-aligned-new -fno-common -stdlib=libc++ -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -Xclang -load -Xclang /Users/kats/zspace/gecko-mac/obj-host-debugopt/build/clang-plugin/libclang-plugin.dylib -Xclang -add-plugin -Xclang moz-check -O3 -fno-omit-frame-pointer -funwind-tables -Werror -fno-strict-aliasing -Werror=format -Wno-shadow -DV8_INTL_SUPPORT  -MD -MP -MF .deps/property-sequences.o.pp   /Users/kats/zspace/gecko-mac/js/src/new-regexp/property-sequences.cc
Summary: Build failure due to #include <version> picking up js/src/new-regexp/VERSION on macOS → Build failure due to #include <version> picking up js/src/new-regexp/VERSION on macOS (unknown type name 'Imported', expected unqualified-id)

The easy fix is for me to change the name of that file.

Assignee: nobody → iireland

Folks, for unrelated reasons I finally ran this issue down. (We've seen it in many different guises.) Sadly, I don't really know what is to be done.

What I believe is happening is an interaction between our system header wrapping, case-insensitive file systems, and clang's permissive #include{_next} handling. First, our system header wrapping tries to wrap some headers with two cases (i.e., string.h and String.h) which is bound to not do the right thing on case-insensitive file systems. But even if we were to make some sense of that, we'd still have the reality that we could wrap a header (like "version.h") and have it redirect to a different header (like "Version.h") somewhere else. That's my guess as to what kats is seeing.

The way I traced this down was to run the preprocessor with line annotations (-P, I think). In my case I could see a benign "debug.h" #include_next-ing into some unrelated system header.

There are flags in clang to warn about these "non-portable" headers, but it doesn't appear possible to force clang to only accept headers that match case. (And indeed, the Windows SDK is littered with includes that assume case-insensitivity.)

So I have no good ideas about what to do. Do we still need the system header wrapping for visibility now that we use much more modern clangs?

On OSX, mach is picking this up for #include <version>.

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

So I have no good ideas about what to do. Do we still need the system header wrapping for visibility now that we use much more modern clangs?

Yes, we do.

We have a linter for mingw capitalization: https://firefox-source-docs.mozilla.org/code-quality/lint/linters/mingw-capitalization.html which tries to catch this sort of issue for Windows headers. I guess we should add the std:: headers to it as well?

Pushed by iireland@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/263182d93843
Change name of irregexp version file r=mgaudet DONTBUILD
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.