Skip to content

With replacements, we can generate a use of a type w/ no definition for that type #251

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fitzgen opened this issue Nov 14, 2016 · 5 comments · Fixed by #255
Closed

With replacements, we can generate a use of a type w/ no definition for that type #251

fitzgen opened this issue Nov 14, 2016 · 5 comments · Fixed by #255

Comments

@fitzgen
Copy link
Member

fitzgen commented Nov 14, 2016

creduce ftw! \o/

Flags: --whitelist-type Rooted -- --std=c++14

Input:

template <typename a> using MaybeWrapped = a;
class Rooted {
  MaybeWrapped<int> ptr;
};
/// <div rustbindgen replaces="MaybeWrapped"
template <typename a> using replaces_MaybeWrapped = a;

Output:

/* automatically generated by rust-bindgen */

#[repr(C)]
#[derive(Debug, Copy)]
pub struct Rooted {
    pub ptr: MaybeWrapped<a>,
}
#[test]
fn bindgen_test_layout_Rooted() {
    assert_eq!(::std::mem::size_of::<Rooted>() , 4usize);
    assert_eq!(::std::mem::align_of::<Rooted>() , 4usize);
}
impl Clone for Rooted {
    fn clone(&self) -> Self { *self }
}

Note how MaybeWrapped is used, but never defined. The <a> tells me we are probably treating it as a named template argument.

@fitzgen
Copy link
Member Author

fitzgen commented Nov 14, 2016

Hmmm.... somehow we end up with a field whose ty == ItemId(7), however we never BindgenContext::add_item(item) where item.id == ItemId(7). Looks like this is another dangling id issue...

@fitzgen
Copy link
Member Author

fitzgen commented Nov 14, 2016

Ah nevermind, it's just our logging that was incomplete. Looks like it is being added as a builtin type:

DEBUG:bindgen::ir::context: add_builtin_item: item = Item { id: ItemId(7), local_id: Cell { value: None }, next_child_local_id: Cell { value: 1 }, canonical_name_cache: RefCell { value: None }, comment: None, annotations: Annotations { opaque: false, hide: false, use_instead_of: None, disallow_copy: false, private_fields: None, accessor_kind: None }, parent_id: ItemId(6), kind: Type(Type { name: Some("MaybeWrapped<int>"), layout: Some(Layout { size: 4, align: 4, packed: false }), kind: ResolvedTypeRef(ItemId(4)), is_const: false }) }

@fitzgen
Copy link
Member Author

fitzgen commented Nov 15, 2016

  • The field has ty: ItemId(7)
  • ItemId(7) is a ResolvedTypeRef(ItemId(4))
  • ItemId(4) is an Alias("MaybeWrapped", ItemId(5))
  • ItemId(5) is a UnresolvedTypeRef(Type(a, kind: Unexposed, decl: Cursor( kind: NoDeclFound, loc: builtin definitions, usr: None), canon: Cursor( kind: NoDeclFound, loc: builtin definitions, usr: None)), Some(Cursor(MaybeWrapped kind: TypeAliasDecl, loc: RootingAPI.hpp:1:29, usr: Some("c:@MaybeWrapped"))), Some(ItemId(1)))

This last point seems to be where we go wrong. We should be creating a named type for ItemId(5) instead of an UnresolvedTypeRef.

@emilio
Copy link
Contributor

emilio commented Nov 15, 2016

Note that the unresolved types change before processing both replacements
and whitelisting, so you should probably take a look at the state of the
context after "resolve_typerefs".

Thanks for digging into this! :)

On Nov 15, 2016 1:04 AM, "Nick Fitzgerald" [email protected] wrote:

The field has ty: ItemId(7)

ItemId(7) is a ResolvedTypeRef(ItemId(4))

ItemId(4) is an Alias("MaybeWrapped", ItemId(5))

ItemId(5) is a UnresolvedTypeRef(Type(a, kind: Unexposed, decl:
Cursor( kind: NoDeclFound, loc: builtin definitions, usr: None), canon:
Cursor( kind: NoDeclFound, loc: builtin definitions, usr: None)),
Some(Cursor(MaybeWrapped kind: TypeAliasDecl, loc: RootingAPI.hpp:1:29,
usr: Some("c:@MaybeWrapped"))), Some(ItemId(1)))

This last point seems to be where we go wrong. We should be creating a
named type for ItemId(5) instead of an UnresolvedTypeRef.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#251 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQwujD5FNPxpq-ZBDMMZmFH-e9vQMrNks5q-PcPgaJpZM4KxvF9
.

bors-servo pushed a commit that referenced this issue Nov 15, 2016
Template alias full and partial specialization improvements.

This doesn't completely fix #251, but fixes other related problems.

r? @fitzgen
@fitzgen fitzgen reopened this Nov 15, 2016
@fitzgen
Copy link
Member Author

fitzgen commented Nov 15, 2016

This is actually fixed -- thanks @emilio :)

@fitzgen fitzgen closed this as completed Nov 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants