Skip to content
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

Fall back to opaque types rather than panicking on parse failure #612

Merged
merged 2 commits into from
Apr 4, 2017

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Apr 4, 2017

Getting closer to figuring out some of the other template related issues in clang 4.0, but not quite ready to land them yet. Figure this should probably land in the meantime. This is just a better fallback in the face of the unknown for panics that we've had reports of in the wild, but which I haven't had time to creduce.

r? @emilio

@fitzgen
Copy link
Member Author

fitzgen commented Apr 4, 2017

Potentially solves #584 but I haven't tried to reduce those failures yet.

Copy link
Contributor

@emilio emilio left a comment

Choose a reason for hiding this comment

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

Not ultra-happy about it, but looks ok. r=me with the following comments addressed.

@@ -424,7 +424,9 @@ impl<'ctx> BindgenContext<'ctx> {
for (id, ty, loc, parent_id) in typerefs {
let _resolved = {
let resolved = Item::from_ty(&ty, loc, parent_id, self)
.expect("What happened?");
.unwrap_or_else(|_| {
Item::new_opaque_type(self.next_item_id(), &ty, self)
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we want to leave a warning here or something.

src/ir/ty.rs Outdated
if let Ok(complex) = CompInfo::from_ty(potential_id,
ty,
Some(location),
ctx) {
Copy link
Contributor

@emilio emilio Apr 4, 2017

Choose a reason for hiding this comment

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

Perhaps using match + a separate variable may look a bit cleaner?

let complex = CompInfo::from_ty(..);
match complex {
    Ok(complex) => TypeKind::Comp(complex),
    Err(..) => {
        warn!(...);
        return Ok(ParseResult::New(...));
    }
}

(or even without the variable)

Also, ditto re. warning.

@fitzgen
Copy link
Member Author

fitzgen commented Apr 4, 2017

@bors-servo r=emilio

Thanks! Review comments addressed.

@bors-servo
Copy link

📌 Commit f2ef3d1 has been approved by emilio

@bors-servo
Copy link

⌛ Testing commit f2ef3d1 with merge ad01eb2...

bors-servo pushed a commit that referenced this pull request Apr 4, 2017
Fall back to opaque types rather than panicking on parse failure

Getting closer to figuring out some of the other template related issues in clang 4.0, but not quite ready to land them yet. Figure this should probably land in the meantime. This is just a better fallback in the face of the unknown for panics that we've had reports of in the wild, but which I haven't had time to creduce.

r? @emilio
@bors-servo
Copy link

☀️ Test successful - status-travis
Approved by: emilio
Pushing ad01eb2 to master...

@bors-servo bors-servo merged commit f2ef3d1 into rust-lang:master Apr 4, 2017
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