Skip to content

Generate bitfield accessor names eagerly#1058

Merged
bors-servo merged 6 commits into
rust-lang:masterfrom
pepyakin:bitfield-accessors
Oct 5, 2017
Merged

Generate bitfield accessor names eagerly#1058
bors-servo merged 6 commits into
rust-lang:masterfrom
pepyakin:bitfield-accessors

Conversation

@pepyakin

@pepyakin pepyakin commented Oct 4, 2017

Copy link
Copy Markdown
Contributor

@fitzgen r?

I'm not sure about deanonymize_fields, as we now assign names to data members and also generate names for the bitfield accessors, but can't come up with a better name.

@highfive

highfive commented Oct 4, 2017

Copy link
Copy Markdown

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!

@fitzgen fitzgen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but I have a few questions below and a couple nitpicks that I'd like to see addressed before we merge this.

Thanks!

Comment thread src/ir/comp.rs Outdated

/// Name of the generated Rust setter for this bitfield.
pub fn setter_name(&self) -> &str {
self.setter_name.as_ref().unwrap()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's replace these unwraps with expects that detail the invariant that is being broken if this panics:

self.setter_name
    .as_ref()
    .expect("`Bitfield::setter_name` should only be called after assigning field names")

And the same for getter_name.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sure!

Comment thread src/ir/comp.rs
}

fn deanonymize_fields(&mut self) {
fn deanonymize_fields(&mut self, ctx: &BindgenContext, methods: &[Method]) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe assign_field_names is a slightly better name for this method now? I'm not married to either name...

Comment thread src/ir/comp.rs Outdated

fn deanonymize_fields(&mut self) {
fn deanonymize_fields(&mut self, ctx: &BindgenContext, methods: &[Method]) {
use std::collections::HashMap;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason that this isn't at the top level? If not, let's put it there.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

Comment thread src/ir/context.rs
///
/// Panics if there is no item for the given `FunctionId` or if the resolved
/// item is not a `Function`.
pub fn resolve_func(&self, func_id: FunctionId) -> &Function {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice :)

Comment thread src/ir/context.rs Outdated
.unwrap()
.deanonymize_fields(self);

self.items.insert(id, item);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have to remove the item and then put it back again? Why doesn't the previous approach work anymore?

This results in two passes over the items, while the previous approach was a single pass because there was no collect call on the iterator, just the for loop.

I doubt it is a ton of overhead, and the code isn't so difficult to follow that I'm worried about code paths where we forget to return the item into the set, but I guess I'm just a little confused and it seems like the old approach was simpler.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, old approach was definitely simpler! I chose this approach because Context was not needed, but now it is. And because of this borrow checker become sad (because we are borrowing self.items). I tried to temporary mem::replace whole self.items but it didn't work out, because we actually need items array (see call to resolve_function in has_method).

So I decided to go approach like in compute_bitfield_units.
I thought that I should factor out this pattern out, but I completely forgot about it 😳

@bors-servo

Copy link
Copy Markdown

☔ The latest upstream changes (presumably #1059) made this pull request unmergeable. Please resolve the merge conflicts.

@pepyakin pepyakin force-pushed the bitfield-accessors branch from 8db2d66 to 9827ad5 Compare October 5, 2017 14:49
Also make impl_partialeq test to also cover impl_debug case.
@pepyakin pepyakin force-pushed the bitfield-accessors branch from 9827ad5 to 3ff8dba Compare October 5, 2017 15:04

@fitzgen fitzgen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Couple nitpicks -- sorry if I missed them in an earlier revision! Will r+ ASAP when they're addressed!

Comment thread src/ir/comp.rs Outdated

/// Get the name of this bitfield.
fn name(&self) -> Option<&str> {
self.data.name()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is identical to <Bitfield as FieldMethods>::name right above -- I don't think it is needed. Am I missing something?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops!

Comment thread src/ir/comp.rs
/// Name of the generated Rust setter for this bitfield.
///
/// Panics if called before assigning bitfield accessor names or if
/// this bitfield have no name.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for these comments :)

Comment thread src/ir/context.rs Outdated
///
/// Panics if attempt to resolve given `ItemId` inside the given
/// closure is made.
fn with_loaned_item<F: FnOnce(&BindgenContext, &mut Item)>(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For legibility, let's move the FnOnce bound to a where clause. Additionally, we should allow the function to return things.

fn with_loaned_item<F, T>(&mut self, id: ItemId, f: F) -> T
where
    F: FnOnce(&BindgenContext, &mut Item) -> T
{
    ...
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree, it is more legible. But rustfmt thinks otherwise.
Is rustfmt used to move bounds into where in the past?

Additionally, we should allow the function to return things.

Good point!

Comment thread src/ir/context.rs
.collect();

for id in comp_item_ids {
self.with_loaned_item(id, |ctx, item| {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This API is pretty nice to use :)

@pepyakin pepyakin force-pushed the bitfield-accessors branch from 3ff8dba to 91796cf Compare October 5, 2017 17:45

@fitzgen fitzgen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!!

@fitzgen

fitzgen commented Oct 5, 2017

Copy link
Copy Markdown
Member

@bors-servo r+

@bors-servo

Copy link
Copy Markdown

📌 Commit 91796cf has been approved by fitzgen

bors-servo pushed a commit that referenced this pull request Oct 5, 2017
Generate bitfield accessor names eagerly

@fitzgen r?

I'm not sure about `deanonymize_fields`, as we now assign names to data members and also generate names for the bitfield accessors, but can't come up with a better name.
@bors-servo

Copy link
Copy Markdown

⌛ Testing commit 91796cf with merge 7bbfb44...

@bors-servo

Copy link
Copy Markdown

☀️ Test successful - status-travis
Approved by: fitzgen
Pushing 7bbfb44 to master...

@bors-servo bors-servo merged commit 91796cf into rust-lang:master Oct 5, 2017
@pepyakin pepyakin deleted the bitfield-accessors branch October 5, 2017 18:43
wolfd added a commit to wolfd/rust-bindgen that referenced this pull request Apr 3, 2026
I've added a `ParseCallbacks` method called `field_name` which is given
the same `FieldInfo` struct that `field_visibility` takes.

I wasn't entirely sure where to change field names, I ended up doing it
in what was `deanonymize_fields` which has been renamed to
`assign_field_names` as suggested by [this
comment](rust-lang#1058 (comment))

Related to rust-lang#1097 and rust-lang#1098
wolfd added a commit to wolfd/rust-bindgen that referenced this pull request Apr 6, 2026
I've added a `ParseCallbacks` method called `field_name` which is given
the same `FieldInfo` struct that `field_visibility` takes.

I wasn't entirely sure where to change field names, I ended up doing it
in what was `deanonymize_fields` which has been renamed to
`assign_field_names` as suggested by [this
comment](rust-lang#1058 (comment))

Related to rust-lang#1097 and rust-lang#1098
pull Bot pushed a commit to sysfce2/rust-bindgen that referenced this pull request May 4, 2026
I've added a `ParseCallbacks` method called `field_name` which is given
the same `FieldInfo` struct that `field_visibility` takes.

I wasn't entirely sure where to change field names, I ended up doing it
in what was `deanonymize_fields` which has been renamed to
`assign_field_names` as suggested by [this
comment](rust-lang#1058 (comment))

Related to rust-lang#1097 and rust-lang#1098
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 this pull request may close these issues.

4 participants