Because the --target was passed after the include path detection, in
cases of cross-compilation, the include path detection would add paths
relevant to the host (e.g. /usr/include/x86_64_linux-gnu on x86_64 linux
while targeting something else), possibly breaking things along the way.
This will prevent common issues in platforms where the Rust target is
not the clang target, like aarch64-apple-darwin (Rust) vs.
arm64-apple-darwin.
We may want to special-case those too when cross-compiling.
* --default-macro-constant-type could be 'signed' or 'unsigned'
* Its default value is 'unsigned' to use u32/u64
for C macro constants that fit into the u32/u64 ranges.
* For old C libraries that use macros as int/long parameter
and/or return value types, their macros are better declared
as i32/i64 if the values fit the i32/i64 ranges,
to be compatible with c_int/c_long types.
They can use "--default-macro-constant-type signed"
Remove needless pushd that was causing trouble with `set -e`
Remove old osx workaround for rvm
Add shebang line
Fix target descriptor
Support LLVM versions 9.0.1+
In Rust 1.45.0, `std::mem::replace` gained the `#[must_use]` attribute,
causing a new diagnostic for some `bindgen` code :
error: unused return value of `std::mem::replace` that must be used
--> src/ir/comp.rs:751:17
|
751 | / mem::replace(
752 | | self,
753 | | CompFields::AfterComputingBitfieldUnits {
754 | | fields,
755 | | has_bitfield_units,
756 | | },
757 | | );
| |__________________^
|
= note: `-D unused-must-use` implied by `-D warnings`
= note: if you don't need the old value, you can just assign the new value directly
error: unused return value of `std::mem::replace` that must be used
--> src/ir/comp.rs:760:17
|
760 | mem::replace(self, CompFields::ErrorComputingBitfieldUnits);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: if you don't need the old value, you can just assign the new value directly
error: aborting due to 2 previous errors
error[E0277]: the trait bound `std::string::String: std::convert::From<&std::string::String>` is not satisfied
--> src/lib.rs:460:37
|
460 | output_vector.push(line.into());
| ^^^^ the trait `std::convert::From<&std::string::String>` is not implemented for `std::string::String`
This itched me when reviewing #1816. Seems easier to switch those to
loop over `get_items()`, but this patch also deduplicates the code a
bit, because all that copy-pasta was also itching me.
These flags don't have ordering dependencies, so the result builder
should be equivalent.
