GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free: gitlabcommitvirtual2021.com

Commit 390f5b9a authored by chrysn's avatar chrysn
Browse files

Drop GCC workarounds

parent acc6211d
......@@ -65,17 +65,6 @@ fn main() {
.into_iter()
.filter(|x| {
match x.as_ref() {
// non-clang flags showing up with arm cortex m3 (eg. stk3700 board)
"-Werror" => false,
"-mno-thumb-interwork" => false,
"-Wformat-overflow" => false,
"-Wformat-truncation" => false,
// non-clang flags showing up for the hifive1 board
"-mcmodel=medlow" => false,
"-msmall-data-limit=8" => false,
"-nostartfiles" => false, // that probably shows up on arm too, but shouldn't matter
"-fno-delete-null-pointer-checks" => false, // seen on an Ubuntu 18.04
// and much more worries on that ubuntu ... maybe just recommend TOOLCHAIN=llvm ?
// Don't pollute the riot-sys source directory
"-MD" => false,
// accept all others
......@@ -156,50 +145,8 @@ static {type_name} init_{macro_name}(void) {{
.sync_all()
.expect("failed to write to riot-c2rust.h");
let c2rust_infile;
let c2rust_outfile;
if cc.find("clang") == None {
// Run through preprocessor with platform specific arguments (cf.
// <https://github.com/immunant/c2rust/issues/305>)
//
// This is only done for non-clang setups; those do not need it (and can profit from the
// unexpanded macros). Also, clang does not have "-fdirectives-only' (but their
// "-frewrite-includes" might do as well if it turns out that this *is* needed even there).
let preprocessed_headercopy = out_path.join("riot-c2rust-expanded.h");
let clang_e_args: Vec<_> = cflags
.iter()
.map(|s| s.clone())
.chain(
vec![
"-E",
"-fdirectives-only",
headercopy.to_str().expect("Non-string path for headercopy"),
"-o",
preprocessed_headercopy
.to_str()
.expect("Non-string path in preprocessed_headercopy"),
]
.drain(..)
.map(|x| x.to_string()),
)
.collect();
let status = std::process::Command::new(cc)
.args(clang_e_args)
.status()
.expect("Preprocessor run failed");
if !status.success() {
println!(
"cargo:warning=Preprocessor failed with error code {}, exiting",
status
);
std::process::exit(status.code().unwrap_or(1));
}
c2rust_infile = "riot-c2rust-expanded.h";
c2rust_outfile = "riot_c2rust_expanded.rs";
} else {
c2rust_infile = "riot-c2rust.h";
c2rust_outfile = "riot_c2rust.rs";
}
let c2rust_infile = "riot-c2rust.h";
let c2rust_outfile = "riot_c2rust.rs";
let output = out_path.join(c2rust_outfile);
match std::fs::remove_file(&output) {
......
// while GCC invoked by RIOT finds the newlib definitions, CLANG does not.
//
// This workaround fixes the fallout (that each time a *timespec is used, a
// `struct timespec` is generated by bindgen); actual solutions might be
// passing on the CC from the RIOT build system.
#ifndef BOARD_NATIVE
struct timespec { char *_unknown;};
#endif
// Copied over from newlib's stdatomic.h -- not sure why it's not included, but
// that's currently needed to get mutexes to build.
#include <stdint.h>
typedef _Atomic(int_least16_t) atomic_int_least16_t;
// Workarounds for https://github.com/rust-lang/rust-bindgen/issues/1636
// (only needed when building for cortex using toolchain=llvm)
#define UINT16_MAX 0xffff
......
// When GCC preprocesses the sources on native, it puts a __float128 into the
// max_align_t which clang does not understand.
#define __float128 long double
// This is currently the only relevant user of stdatomic.h. As it doesn't
// access its relevant atomic field from static inlines (and thus from built
// Rust) and forbids users from touching it themselves, we can work around
......
......@@ -21,7 +21,7 @@
//! `CFLAGS_WITH_MACROS` and `INCLUDES`; both need to be passed in to the Rust
//! build system as a `RIOT_CFLAGS` environment variable.
//!
//! In addition, riot-sys also needs to know the C compiler to properly expand the
//! In addition, riot-sys for some time needed to know the C compiler to properly expand the
//! header files before transpilation; that information is passed in `RIOT_CC`.
//!
//! When using riot-sys, it is usually easiest to run from a target within the Make
......@@ -41,6 +41,7 @@
//! The `RIOT_CC` and `RIOT_CFLAGS` are made available to dependent modules through
//! Cargo; see [riot-wrappers]'s build.sh for an example.
//!
//! ## Transition to compile-commands
//!
//! As an alternative to passing `RIOT_CFLAGS` and `RIOT_CC`, the path to a
//! compile-commands.json file can be passed in `RIOT_COMPILE_COMMANDS_JSON`, with
......@@ -50,6 +51,11 @@
//! passed down to dependent crates as they were before. (The passed down CC will just always be
//! clang).
//!
//! In the course of this transition, workarounds for GCC CFLAGS have been removed from riot-sys.
//! Thus, you'll either have to pick `TOOLCHAIN=llvm` for thw whole build, or use the
//! `RIOT_COMPILE_COMMANDS_JSON` mechanism (with a recent enough RIOT version to support it) that
//! produces working CFLAGS even when GCC is used as the main C compiler.
//!
//! ## Extension
//!
//! Currently, only a subset of all the RIOT headers is processed; all the relevant
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment