[WebAssembly] Define __unix__ as part of the wasm target

[jgravelle-google]

Summary

Unix is a convenient common denominator for embeddings to implement
syscalls for. This makes it explicit that wasm is unix-y

[dschuff]

Also it matches asm.js @sunfish is planning on unifying the triples, and this will be part of that (and there may be more defines that we want to add and/or subtract), but for now it makes more of the emscripten test suite pass, so LGTM

[sunfish]

When adding new predefined macros, please also add the new macros to test/Preprocessor/init.c (and remove negative tests that no longer apply).

Also though, I'd also like to understand this a little more. Even with emulation, there will be limits to how Unixy a Web environment could be (though a non-Web environment could potentially do more). Which tests start passing with this?

[jgravelle-google]

For the emscripten testsuite, specifically test_zlib relies on #ifdef __unix__ to #include <unistd.h>, which it needs. The rest of the unistd tests don't actually care. So we could make that test pass by explicitly adding a define for unix for it, but I figure it would be better to have things as similar as possible between wasm and asmjs.

[sunfish]

The other main way we could provide __unix et al would be to add them to tools/shared.py in Emscripten (see the comment "wasm target does not automatically define emscripten stuff"). It's not clear to me whether that's better than adding the macros to clang itself or not.

Currently Unixy-like functionality is provided by Emscripten facilities, and one could think of (hypothetical future) non-Emscripten clang as targeting more of the bare metal of WebAssembly which isn't inherently Unixy. Thoughts?

However, I'm also open to just adding it to clang for now and re-evaluating later, which we can do since we don't yet have a stable ABI.

[jgravelle-google]

I think you're right, it's the Emscripten embedding that's unixy, therefore Emscripten should be responsible for telling clang to be unixy.

To play devil's advocate, it might be advantageous for all compile-to-wasm code to assume a common environment, and unix is a reasonable thing to arbitrarily standardize on. But it's probably more advantageous to not decide that at this level.

Double-alternatively it might make sense to have a wasm32-unknown-emscripten triple, and let that determine whether we're unixy or not in clang.

[dschuff]

Yeah, I don't mean for this to be the final word; mostly this just matches asm.js.
I do agree with you that the unixy stuff goes with the emscripten environment rather than wasm per se. I had thought we might define emscripten as an "OS" (i.e. the third or maybe even 4th part of the triple) in LLVM, because currently it affects not just defines but also things like emscripten exception handling (which we currently use a backend flag for).

[jgravelle-google]

Abandoning in favor of https://github.com/kripken/emscripten/pull/4718

lib/Basic/Targets.cpp

class WebAssemblyOSTargetInfo : public OSTargetInfo<Target> {
   void getOSDefines(const LangOptions &Opts, const llvm::Triple &Triple,
                     MacroBuilder &Builder) const final {
     // A common platform macro.
     if (Opts.POSIXThreads)
       Builder.defineMacro("_REENTRANT");
     // Follow g++ convention and predefine _GNU_SOURCE for C++.
     if (Opts.CPlusPlus)
       Builder.defineMacro("_GNU_SOURCE");
+
+    DefineStd(Builder, "unix", Opts);
   }
 
   // As an optimization, group static init code together in a section.
   const char *getStaticInitSectionSpecifier() const final {
     return ".text.__startup";
   }
 
 public: