* 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
