clang_getAddressSpace was found as a clang 5.0+ API by comparing the "tools/libclang/libclang.exports" files in the clang source code.
"clang_getAddressSpace" exists for 5.0.0 and 10.0.0, but not for 4.0.1.
Differential Revision: https://phabricator.services.mozilla.com/D78374
This also does a few remaining python 2 incompatible changes to
.configure files.
Differential Revision: https://phabricator.services.mozilla.com/D69538
--HG--
extra : moz-landing-system : lando
I need this to support individual #[cfg] in enum variants, which is used for
Image::PaintWorklet.
Differential Revision: https://phabricator.services.mozilla.com/D62160
--HG--
extra : moz-landing-system : lando
v0.12.2 at least is needed to have proper v2 lockfile support.
But v0.13.0 contains extra fixes, and features that wgpu and the style system
plan to use, so let's just update to that.
Differential Revision: https://phabricator.services.mozilla.com/D61334
--HG--
extra : moz-landing-system : lando
This is needed to support min() / max() / clamp(), as LengthPercentage will have
a potential heap allocation and the current copy-assignment operators just do
bitwise copies.
Differential Revision: https://phabricator.services.mozilla.com/D57300
--HG--
extra : moz-landing-system : lando
This includes more bitflag operators, which means we can remove some slightly
ugly code.
Differential Revision: https://phabricator.services.mozilla.com/D56308
--HG--
extra : moz-landing-system : lando
Just like C++14 sized deallocation support, we don't want to support
this. We shouldn't be using `new` on over-aligned types anyway.
Differential Revision: https://phabricator.services.mozilla.com/D41819
--HG--
extra : moz-landing-system : lando
In the clang-cl 9 case where we have semicolon-separated paths, the `dirs` variable is never read, so the libclang detection fails.
Differential Revision: https://phabricator.services.mozilla.com/D35825
--HG--
extra : moz-landing-system : lando
The current setup for bindgen relies on either finding clang/libclang
from the output of llvm-config, or from the paths given via the
configure flags --with-clang-path/--with-libclang-path.
One _very_ common problem is that the llvm-config we end up using does
not correspond to the clang used for compilation, which has some
undesirable side effect, like failing to build.
So instead of relying on llvm-config, we do the following:
- when the compiler is clang, we just use that
- when the compiler is clang-cl, we use clang from the same directory
- otherwise, we either try to find clang in PATH, or rely on
--with-clang-path.
Once clang is found, we try to deduce the location of the corresponding
libclang via the output of `clang -print-search-dirs`, or rely on
--with-libclang-path.
Differential Revision: https://phabricator.services.mozilla.com/D33241
--HG--
extra : moz-landing-system : lando
We need this to auto-generate the copy-constructor for TransformOperation,
without which the patch wouldn't build.
Differential Revision: https://phabricator.services.mozilla.com/D30799
--HG--
extra : moz-landing-system : lando
We already do this for the compiler that we detect via
toolchain.configure...but as the comment in `basic_bindgen_cflags`
alludes to, we don't actually use that compiler here. We use a much
more bare-bones compiler, so we have to add the necessary flags manually.
We need to make `--with-macos-sdk` a `js_option` so that uses of bindgen
in the JS engine will receive the proper flags.
Differential Revision: https://phabricator.services.mozilla.com/D30239
--HG--
extra : moz-landing-system : lando
Before this patch, we first find an executable, then check the version. So if
the first executable we find is outdated, we won't look for others.
Instead, check each of them for different versions manually. This will also
unblock bug 1540533, since at that point we know that we'll be able to find
a cbindgen with the right version.
Differential Revision: https://phabricator.services.mozilla.com/D27890
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
When the build system compiler is clang, and bindgen autodetection
actually finds a different clang via llvm-config, or a different clang
was given with --with-clang-path, we do want the proper flags to be
used for that clang, so we always get the right flags for that clang
instead of trying to shortcut.
Bug 1526857 will take care of making things more proper, while this is a
quick fix to unbreak builds in some unfortunately common kind of local
setups.
Differential Revision: https://phabricator.services.mozilla.com/D19328
--HG--
extra : moz-landing-system : lando
basic_bindgen_cflags's function is to set some flags for use with
rust-bindgen through clang/libclang for C++ code. Part of the flags it
sets are for the C++ standard, and the target.
Unfortunately, some of the logic wrt target-specific flags is currently
broken. It wants to apply per-compiler flags on Windows, but fails to do
so. First, because the condition test is wrong, and second, because it
only cares about msvc and not clang-cl.
OTOH, we already have those flags when the compiler is clang or
clang-cl. And we already have code to get the right flags for a given
compiler. So when the compiler is not clang or clang-cl, we can use that
to get the right flags for the clang we're going to use for bindgen.
Depends on D18316
Differential Revision: https://phabricator.services.mozilla.com/D18317
--HG--
extra : moz-landing-system : lando
Also, while here, replace subprocess.check_output with check_cmd_output.
Depends on D17771
Differential Revision: https://phabricator.services.mozilla.com/D17772
--HG--
extra : moz-landing-system : lando
JS, at least, doesn't need bindgen at this point. If JS does start
requiring bindgen under certain build configurations, we'll have to
figure out what to do about the bindgen dependency at that point:
require bindgen always, or just require bindgen for the
configuration(s).
Emilio Cobos Álvarez
Coroiu Cristina
Mitchell Hentges
Dzmitry Malyshau
Mihai Alexandru Michis
Mike Hommey
Ricky Stewart
Tooru Fujisawa
Nathan Froyd
David Major
Ciure Andrei
Alexis Beingessner
Tom Ritter
Mark Banner
Benjamin Bouvier