Skip to content

analysis: Account for template instantiations of opaque types in the derive debug analysis. #842

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

Merged
merged 1 commit into from
Jul 22, 2017

Conversation

emilio
Copy link
Contributor

@emilio emilio commented Jul 22, 2017

We have a special-case for them in codegen to generate a blob, that can derive
debug.

This is a regression from #824, and hit stylo.

@highfive
Copy link

warning Warning warning

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

…derive debug analysis.

We have a special-case for them in codegen to generate a blob, that can derive
debug.

This is a regression from rust-lang#824, and hit stylo.
@emilio emilio force-pushed the derive-debug-opaque-inst branch from 7e80988 to bff026c Compare July 22, 2017 00:51
@emilio
Copy link
Contributor Author

emilio commented Jul 22, 2017

r? @fitzgen

@Manishearth
Copy link
Member

@bors-servo r+

@bors-servo
Copy link

📌 Commit bff026c has been approved by Manishearth

@highfive highfive assigned Manishearth and unassigned fitzgen Jul 22, 2017
@bors-servo
Copy link

⌛ Testing commit bff026c with merge 038381c...

bors-servo pushed a commit that referenced this pull request Jul 22, 2017
analysis: Account for template instantiations of opaque types in the derive debug analysis.

We have a special-case for them in codegen to generate a blob, that can derive
debug.

This is a regression from #824, and hit stylo.
@bors-servo
Copy link

☀️ Test successful - status-travis
Approved by: Manishearth
Pushing 038381c to master...

@bors-servo bors-servo merged commit bff026c into rust-lang:master Jul 22, 2017
@Manishearth
Copy link
Member

This wasn't enough to fix the bug.

I poked around and it seems like when handling the TypeKind::Copy for ImageValue we check if nsRefPtrHashtable (not nsRefPtrHashtable<blah> -- I printed the disambuguated name and it was just the struct) is in the "cannot derive debug" set.

It also seems like we generate a struct nsRefPtrHashtable {} that is never used, as well as a layout test for the opaque (refptrhashtable containing) mDocumentTable field of nsBindingManager. This may be related.

The following diff fixes it but I'm not really sure if that's the correct solution.

diff --git a/src/ir/analysis/derive_debug.rs b/src/ir/analysis/derive_debug.rs
index b9b0be1..57ac6df 100644
--- a/src/ir/analysis/derive_debug.rs
+++ b/src/ir/analysis/derive_debug.rs
@@ -226,7 +226,18 @@ impl<'ctx, 'gen> MonotoneFramework for CannotDeriveDebug<'ctx, 'gen> {
                     .any(|f| {
                         match *f {
                             Field::DataMember(ref data) => {
-                                self.cannot_derive_debug.contains(&data.ty())
+                                if self.cannot_derive_debug.contains(&data.ty()) {
+                                    let item = self.ctx.resolve_item(data.ty());
+                                    if item.is_opaque(self.ctx, &()) {
+                                        if let Some(layout) = item.as_type().and_then(|t| t.layout(&self.ctx)) {
+
+                                            return !layout.opaque().can_trivially_derive_debug(&self.ctx, ());
+                                        }
+                                    }
+                                    true
+                                } else {
+                                    false
+                                }
                             }
                             Field::Bitfields(ref bfu) => {
                                 bfu.bitfields()

Thoughts?

@Manishearth Manishearth mentioned this pull request Jul 23, 2017
@emilio emilio deleted the derive-debug-opaque-inst branch July 24, 2017 12:09
fn default() -> Self { unsafe { ::std::mem::zeroed() } }
}
#[repr(C)]
#[derive(Debug, Default, Copy)]
Copy link
Member

Choose a reason for hiding this comment

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

The whole point was to ensure that this doesn't derive debug, right?

template<typename T>
class OpaqueTemplate {
T mData;
bool mCannotDebug[40];
Copy link
Member

Choose a reason for hiding this comment

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

I think instantiating with T = bool so that alignment is lower, or replace bool mCabnnotDebug[40] with unsigned long long mCannotDebug[40] should do the trick.

Copy link
Member

Choose a reason for hiding this comment

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

Or s/40/400/

@fitzgen
Copy link
Member

fitzgen commented Jul 24, 2017

@Manishearth

Thoughts?

This is close, but not quite exactly what I'd write. I think we want to push this is_opaque check down into the field's item's constraint invocation, rather than special casing data members. Because we also need this logic for bases, and template arguments, etc... so ideally it should be done just once.

I'll make a PR in a bit.

bors-servo pushed a commit that referenced this pull request Jul 24, 2017
Derive debug and opaque types

See each commit for details.

Follow up to #842.

r? @emilio or @Manishearth
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.

5 participants