Fix for #232
This adds a type prefix for associated constants to avoid namespace
collisions. It also adds error invocation in the rare but existing
cases where an collisions still happens in the constant namespace.
Boris hit this because he used #[repr(C)] instead of #[repr(u8)].
We were incorrectly writing the generic arguments twice for those.
I missed this difference in #219.
Fixes#225.
I want this to move around slices and boxes across the style system, while
preserving the option size optimizations when they're fully in a repr(Rust)
data-structure.
This is sound because NonNull is repr(transparent):
https://doc.rust-lang.org/src/core/ptr.rs.html#2847
I renamed simplify_option_to_ptr to simplify_standard_types because that's what
it does now.
ABI-wise for NonNull<T> it's guaranteed via repr(transparent). For
Option<NonNull<T>> it is as well, though I've asked in #rustc to confirm.
The LLVM IR of:
```
pub extern "C" fn foo(ptr: Option<::std::ptr::NonNull<i32>>) {}
```
is:
```
define void @foo(i32*) unnamed_addr #0 !dbg !310 {
start:
%ptr = alloca i32*, align 8
store i32* %0, i32** %ptr, align 8
call void @llvm.dbg.declare(metadata i32** %ptr, metadata !327, metadata
!DIExpression()), !dbg !328
ret void, !dbg !329
}
```
Which is the same as for:
```
pub extern "C" fn foo(ptr: ::std::ptr::NonNull<i32>) {}
```
Except without the nonnull annotation.
And the same as for:
```
pub extern "C" fn foo(ptr: *mut i32) {}
```
Going to need this if I ever aim to generate TransformOperation bindings and
remove a bunch of slow and ugly Gecko code:
https://searchfox.org/mozilla-central/rev/80ac71c1c54af788b32e851192dfd2de2ec18e18/servo/components/style/values/generics/transform.rs#189
With the caveat that I'll need to remove the options, but I can manage to do
that.
This also fixes a bunch of renaming bugs that I found while at it.
This patch has the gotcha that we need to remove the assertion of no-underscores
in mangled names... But I think it should be fine, and I'd rather not do a more
breaking change.
You can generate conflicting names in C using enum variants with the same name
as a struct regardless, for example, so I don't think this is terribly
important.
* handle associated constants and struct literals
This aims to fix#100 by adding parsing support for associated constants, and
struct literal expressions.
It duplicates some of the parsing for constants, but sadly ImplItemConst and
ImplConst (as well as their children) don't share a common trait
that would allow for genericity.
It also uses the same namespace for both constants and associated
constants, which could cause conflicts in valid Rust with shared const names in
different scopes.
The struct literals use the standard C99 syntax. Do mind that the
limitations on literal expressions still apply.
* added test cases
* fix formatting
Added impl of `fmt::Display` for `Cfg`
Added `fn matched_defines(…)` for filtering for matches in `[defines]`
Changes semantic of `has_defines` from `∀` to `∃` (i.e. all -> one or more)
Changed `write_before` to use `matched_defines`
Added logging of warning for omitted `#[cfg(…)]`s
Added expectations for `mod_attr` test project
Renamed function arguments in `mod_attr` test project
Rustfmt
Introduced `Condition` type to ensure correct API usage of `Cfg`
Merged `Condition::Boolean` and `Condition::Named` into `Condition::Define`
Removed `DefineConfig` and `MissingDefineBehavior`.
(Was getting a bit ahead of myself with these.)
Rustfmt
Currently, `cbindgen` uses the `--all-features` flag when expanding a
dependent crate. However, this may not be desirable in a number of
cases:
- Some C APIs may be gated by a feature flag and would not be present
in the final cdylib depending on the features provided (for instance
one could want to have the ability to build a "debug" version of the
library which provides extra unstable hooks). In such cases, a
programmatic `cbindgen` call in a build script would want to use only
the features that will get used in the current build.
- Some features may bring in large dependencies and/or potentially
increase compilation time without affecting the FFI surface, and it
would be faster and more efficient to disable them when running
`cbindgen`.
- Some features may require external libraries and/or hardware (e.g.
dependencies on GPU libraries such as CUDA) that may not be available
on the current machine without affecting the FFI surface.
To alleviate this problem, this PR adds an extended version of the
`parse.expand` configuration key, allowing control over the features
used when expanding in a way similar to the way cargo handles extended
dependencies (although note that there is a single version of each key,
since the features refer to the features of the current crate). So for
instance instead of writing `expand = ["euclid"]` one would write:
```
[parse.expand]
crates = ["euclid"]
```
which is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = false
default_features = true
features = ["feature1", "feature2"]
```
Note that `all_features` is set to `false` by default in order to match
cargo's behavior.
For backwards compatibility, the old syntax `expand = ["euclid"]` is
still supported and is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = true
default_features = true
features = null
```
In this case, `all_features` is set to `true` in order to match the
previous behavior of cbindgen.
cbindgen currently assumes that the `Cargo.lock` is in directly in the
crate directory as a sibling to `Cargo.toml`; however that is usually
not the case inside a workspace.
Instead, this PR extracts the workspace root from the output of `cargo
metadata` [1] (already used to get a list of packages) and uses the
`Cargo.lock` from there.
1. This is available since Rust 1.24; see rust-lang/cargo#4940
Emilio Cobos Álvarez
IGI-111
Mrmaxmeier
konstin
Vincent Esche
Basile Clement
Ryan Hunt
Alexis Beingessner
Johan Anderholm
Dan Robertson
Dan Robertson
Ingvar Stepanyan
Kartikaya Gupta