Age | Commit message (Collapse) | Author |
|
|
|
Remove derive-partialeq-template-inst test.
Add comments.
Don't implement PartialEq for incomplete arrays
Handle opaque bases and template instantiations
Extract constrain_type.
Extract `is whitelisted?` check
Add failing partialeq-anonfield
join for comps
Fix: return insert if not whitelisted
Delegate TypeRefs and alias to constrain_join.
Delegate Template instantiations to constrain_join
Add derive-partialeq-pointer.hpp test
Update comment.
Fix layout alignment larger that array limit
Add missing test for derive-partialeq-anonfield.rs
Clean
Clean
Fix typo in opaque-template-inst-member test
Remove redudant stmt
Add comment on can_supersede.
Format impl_partialeq and leave a comment
Extract requires_storage into it's own function.
Clean
|
|
Strongly type ids
* [X] `TypeId`
* [X] `ModuleId`
* [x] `VarId`
* [x] `FunctionId`
|
|
Its not just item ids now, and that name was pretty long...
|
|
|
|
|
|
And also allow ID comparison across ID types, as this makes implementing the
above much easier.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The definition of a template is always a type, so it should be a TypeId rather
than an ItemId. Template arguments, on the other hand are not guaranteed to be
types. They can be constant values, for example.
|
|
This commit makes certain `TypeKind`s that can only reference other types use
`TypeId` instead of `ItemId`.
|
|
|
|
None of the callers were passing template parameters.
|
|
|
|
This commit also makes `BindgenContext::resolve_type` take a `TypeId`, and adds
unchecked conversions everywhere that we call it. Next, I'm going to go through
the code base, replacing these unchecked conversions with checked ones, and
tightening up types as I go.
|
|
Add @pepyakin to the list of reviewers ๐ ๐ ๐
r? @pepyakin
|
|
|
|
fitzgen:wrong-parent-id-with-nested-class-declarations, r=emilio
ir: Prefer using known semantic parents
When choosing a parent ID for a type that we are parsing, prefer known semantic parents over the provided parent ID. It seems like we shouldn't even be passing explicit parent IDs around (they're often buggy), and instead should expand the `known_semantic_parent` infrastructure, but I'll leave that to some future work.
Fixes #1048
r? @emilio
|
|
When choosing a parent ID for a type that we are parsing, prefer known semantic
parents over the provided parent ID. It seems like we shouldn't even be passing
explicit parent IDs around (they're often buggy), and instead should expand the
`known_semantic_parent` infrastructure, but I'll leave that to some future work.
Fixes #1048
|
|
Issue #1037: pass all derive-enabling flags in bindgen for csmith driver
|
|
|
|
book: Clean up the C++ section some more
Trying to set expectations for what we can do with C++ a little better.
r? @emilio
|
|
Trying to set expectations for what we can do with C++ a little better.
|
|
Csmith tweaks
r? @e00E or @emilio or @pepyakin whoever wants to get here first ;)
|
|
This makes us fall over flat on our faces almost immediately...
|
|
This allows us to have multiple processes generating C files with C-Smith and
testing them on bindgen without stepping on each others' toes.
|
|
Enable --rustfmt-bindings by default
This patch flips --rustfmt-bindings to --no-rustfmt-bindings and enables
formatting by default. If rustfmt is not accessible, a warning is
printed and the bindings are printed unformatted.
Addresses #977.
|
|
codegen: Avoid generating wrong type for enums with unknown representation
Fixes #1025
|
|
csmith fuzzing
ref #969
An initial version of a script that fuzzes bindgen with csmith. I ran it for maybe 1000 iterations and it did not find something wrong. The programs generated by csmith are probably too simple type wise.
Here is an example output of what csmith generates:
``` C
/* --- Struct/Union Declarations --- */
union U2 {
uint64_t f0;
const signed f1 : 18;
};
union U4 {
const volatile signed f0 : 1;
volatile int16_t f1;
int32_t f2;
int8_t * const f3;
volatile int64_t f4;
};
union U5 {
const int8_t * f0;
volatile int8_t f1;
uint16_t f2;
unsigned f3 : 22;
};
/* --- GLOBAL VARIABLES --- */
static int8_t g_3[8] = {0x47L,0xE8L,0x47L,0x47L,0xE8L,0x47L,0x47L,0xE8L};
static int32_t g_25 = 0x3421AD7BL;
static union U5 g_40 = {0};/* VOLATILE GLOBAL g_40 */
static int32_t g_43[4][3] = {{(-10L),(-10L),(-10L)},{(-10L),(-10L),(-10L)},{(-10L),(-10L),(-10L)},{(-10L),($static int32_t * volatile g_42 = &g_43[0][0];/* VOLATILE GLOBAL g_42 */
static int32_t * volatile g_50 = &g_43[2][0];/* VOLATILE GLOBAL g_50 */
static int32_t g_53 = (-9L);
static union U4 g_57 = {0x9C113E7BL};/* VOLATILE GLOBAL g_57 */
/* --- FORWARD DECLARATIONS --- */
static union U4 func_1(void);
static int16_t func_4(int32_t p_5);
static int32_t func_6(int32_t p_7, union U2 p_8, int8_t * p_9);
static int32_t func_10(uint32_t p_11, int8_t * p_12, int8_t * p_13);
static int8_t * func_14(int32_t p_15, union U2 p_16);
static union U2 func_28(const uint64_t p_29, int8_t * p_30, uint32_t p_31);
static union U5 func_34(uint32_t p_35);
```
|
|
lib: Print warnings to stderr instead of stdout.
Seems like the right thing to do, and allows me to test stuff piping to rustc instead of saving to a file.
|
|
Make objc-related expectations compile
Fixes #1004.
After looking at how `msg_send!` is supposed to be used, I realized that
we were erroneously passing type signatures to it.
The expectations compile now, but some of them are not formatted properly.
My guess is that `rustfmt` does not know how to format the following:
```
msg_send!(obj, arg1:1 arg2:2 arg3:3)
```
Notice the lack of separatros between the `arg`s.
Any advice on how to proceed here is appreciated.
r? @fitzgen
|
|
Always check out test headers and expectations as LF
Addresses #1023.
The line endings accidentally don't matter for the majority of the tests because we pass both the generated .rs files and expectations .rs files through rustfmt, which normalizes the line endings to LF. But this change makes it explicit that we expect to test against files with LF line endings.
|
|
|
|
|
|
|
|
Create an FAQ section in the book
I feel like we've had to anwer these questions multiple times... Good to be able to just point people to these canonical answers instead of repeating ourselves.
r? @emilio
|
|
Some little deriving cleanups
See each commit for details.
r? @emilio
|