[LLVM 4.0] Handle new DIFlags enum #37857

shepmaster · 2016-11-18T16:14:04Z

No description provided.

rust-highfive · 2016-11-18T16:14:10Z

(rust_highfive has picked a reviewer for you, use r? to override)

shepmaster · 2016-11-18T16:14:54Z

@rkruppe - You'll note that I took a few pieces out that weren't directly related to DINode, those have been moved to separate commits.

alexcrichton · 2016-11-18T16:31:31Z

r? @michaelwoerister

hanna-kruppe · 2016-11-18T16:48:54Z

src/rustllvm/RustWrapper.cpp

+#if LLVM_VERSION_GE(4, 0)
+  auto Flags = DINode::FlagPrototyped;
+#else
+  unsigned Flags = DINode::FlagPrototyped;


Can't we avoid these version checks by just unconditionally doing auto Flags = ...;? ~~(here and in the rest of this file)?~~

In this case, yes, but I wanted to keep it consistent with the majority case of FlagZero, which I think needs to be different.

hanna-kruppe · 2016-11-18T16:49:49Z

src/rustllvm/RustWrapper.cpp

+#if LLVM_VERSION_GE(4, 0)
+  auto Flags = DINode::FlagZero;
+#else
+  unsigned Flags = 0;


~~All the DINode::FlagFoo names seem to exist in LLVM 3.7 so why not just use those instead of magic numbers?~~

Edit: Nevermind, DINode::FlagZero is the one exception that didn't exist in 3.7 =/ I'd still like a name for that magic number.

Hmm, could you point me to where FlagZero is defined? I was under the impression that that value did not exist until the enum change. Previously, it was just hardcoded as 0.

You are right, it did not exist, see edit above.

I've replaced this with a single #ifdef and removed the conditions from each case. Check it out?

michaelwoerister · 2016-11-18T17:51:48Z

Thanks for the PR!
I think it would be better to keep exposing the flags to Rust though. For example, if we want to fix #9228, we need to have this functionality available. Could we follow a similar pattern as with LLVMRustLinkage for example?

shepmaster · 2016-11-18T18:20:54Z

keep exposing the flags to Rust though

I was really, really afraid you'd say that. That enum business is terribly verbose (and annoying).

Not to say I'm not going to, I'm just whinging.

shepmaster · 2016-11-18T18:50:13Z

keep exposing the flags to Rust though

Oh right, I remember why this is more difficult than LLVMRustLinkage; these are actually bitflags, not an enum. Is there an example of marshalling such a type already?

michaelwoerister · 2016-11-18T18:58:19Z

I was really, really afraid you'd say that. That enum business is terribly verbose (and annoying).

I'm sorry, I know :)

I would probably use the bitflags! macro on the Rust side (so I get something type safe in Rust that also has a predictable C-representation) and then do a mapping on the C++ side like with LLVMRustLinkage so we don't depend on LLVM not changing values.

shepmaster · 2016-11-18T22:12:06Z

OK, this is going to conflict with #37831 because someone removed the bitflags crate that this commit is going to want to use. 😈 Hopefully we can get that submitted soon so I can re-add it.

sanxiyn · 2016-11-21T14:47:29Z

#37831 landed.

shepmaster · 2016-12-01T16:40:09Z

@michaelwoerister please give this another look; I've rebased and been able to compile the current master branch and the LLVM 4.0 branch is off compiling somewhere in stage1.

shepmaster · 2016-12-01T22:40:22Z

Ah, looks like I need to look at the various LLVM versions to see when each flag was introduced. I assume I should not include any flags that are not supported in the oldest version of LLVM we support, because otherwise we'd have no ability to do anything with those flags with those older versions.

michaelwoerister

Looks great! I'll be happy to r+ after you've addressed the nits.

michaelwoerister · 2016-12-02T15:03:30Z

src/librustc_llvm/ffi.rs

+    bitflags! {
+        #[repr(C)]
+        #[derive(Debug, Default)]
+        flags DIFlags: ::libc::c_uint {


Since it's uint32_t on the C++ side, we should use libc::uint32_t here too.

michaelwoerister · 2016-12-02T15:18:49Z

src/rustllvm/RustWrapper.cpp

+
+    if (is_set(flags & LLVMRustDIFlags::FlagPrivate))             { result |= DINode::DIFlags::FlagPrivate; }
+    if (is_set(flags & LLVMRustDIFlags::FlagProtected))           { result |= DINode::DIFlags::FlagProtected; }
+    if (is_set(flags & LLVMRustDIFlags::FlagPublic))              { result |= DINode::DIFlags::FlagPublic; }


Since the visibility bits are not really flags, but rather a 2-bit number, this is not quite correct.

private = 01 protected = 10 public = 11

The result will be correct, but it I'm not sure that that would hold if they changed the encoding on the LLVM side. Something like the following would be a better conceptual fit:

switch flags & 0x3 { LLVMRustDIFlags::FlagPrivate: result |= DINode::DIFlags::FlagPrivate; break; LLVMRustDIFlags::FlagProtected: result |= DINode::DIFlags::FlagProtected; break; LLVMRustDIFlags::FlagPublic: result |= DINode::DIFlags::FlagPublic; break; }

switch (flags & 0x3) { is not possible because I've attempted to use a typesafe enum (enum class). Would you like me to discard that and move to a traditional plain enum?

I could do this though:

+inline LLVMRustDIFlags visibility(LLVMRustDIFlags f) { + return static_cast<LLVMRustDIFlags>(static_cast<uint32_t>(f) & 0x3); +} + + switch (visibility(flags)) { + case LLVMRustDIFlags::FlagPrivate: + result |= DINode::DIFlags::FlagPrivate; + break; + case LLVMRustDIFlags::FlagProtected: + result |= DINode::DIFlags::FlagProtected; + break; + case LLVMRustDIFlags::FlagPublic: + result |= DINode::DIFlags::FlagPublic; + break; + default: + // The rest are handled below + break; + } +

In LLVM 4.0, this enum becomes an actual type-safe enum, which breaks all of the interfaces. Introduce our own copy of the bitflags that we can then safely convert to the LLVM one.

michaelwoerister · 2016-12-03T19:13:04Z

@bors r+

Thanks a lot, @shepmaster! I know this can be tedious stuff but future generations of Rust compiler hackers will thank you :)

bors · 2016-12-03T19:13:05Z

📌 Commit 757a9ce has been approved by michaelwoerister

bors · 2016-12-04T02:25:28Z

⌛ Testing commit 757a9ce with merge 125474d...

[LLVM 4.0] Handle new DIFlags enum

shepmaster · 2016-12-04T05:11:12Z

I know this can be tedious stuff but future generations of Rust compiler hackers will thank you :)

Aww, I know I'm grumbly, but in my heart of hearts I also know the code is better after the review. Besides, with the work we are doing for LLVM, it's not unusual for me to be that future hacker.

bors · 2016-12-04T06:11:36Z

rust-highfive assigned aturon Nov 18, 2016

shepmaster mentioned this pull request Nov 18, 2016

Upgrade to LLVM 4.0 #37609

Closed

23 tasks

rust-highfive assigned michaelwoerister and unassigned aturon Nov 18, 2016

hanna-kruppe reviewed Nov 18, 2016

View reviewed changes

shepmaster force-pushed the llvm-4.0-dinodes branch from a9053df to 6907ce1 Compare November 18, 2016 17:15

shepmaster force-pushed the llvm-4.0-dinodes branch from 6907ce1 to 956a238 Compare December 1, 2016 16:38

shepmaster force-pushed the llvm-4.0-dinodes branch from 956a238 to 65f787e Compare December 1, 2016 17:31

shepmaster changed the title ~~[LLVM 4.0] Handle new DINode enum~~ [LLVM 4.0] Handle new DIFlags enum Dec 1, 2016

shepmaster force-pushed the llvm-4.0-dinodes branch from 65f787e to e466b83 Compare December 2, 2016 14:35

michaelwoerister approved these changes Dec 2, 2016

View reviewed changes

shepmaster added 2 commits December 2, 2016 21:13

[LLVM] Introduce a stable representation of DIFlags

dbdd60e

In LLVM 4.0, this enum becomes an actual type-safe enum, which breaks all of the interfaces. Introduce our own copy of the bitflags that we can then safely convert to the LLVM one.

[LLVM 4.0] Support new DIFlags enum

757a9ce

shepmaster force-pushed the llvm-4.0-dinodes branch from e466b83 to 757a9ce Compare December 3, 2016 02:14

bors added a commit that referenced this pull request Dec 4, 2016

Auto merge of #37857 - shepmaster:llvm-4.0-dinodes, r=michaelwoerister

125474d

[LLVM 4.0] Handle new DIFlags enum

bors merged commit 757a9ce into rust-lang:master Dec 4, 2016

This was referenced Dec 4, 2016

struct field reordering and optimization #37429

Merged

Emit DW_AT_main_subprogram #38109

Merged

shepmaster deleted the llvm-4.0-dinodes branch April 25, 2018 19:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[LLVM 4.0] Handle new DIFlags enum #37857

[LLVM 4.0] Handle new DIFlags enum #37857

shepmaster commented Nov 18, 2016

rust-highfive commented Nov 18, 2016

shepmaster commented Nov 18, 2016

alexcrichton commented Nov 18, 2016

hanna-kruppe Nov 18, 2016 •

edited

Loading

shepmaster Nov 18, 2016

hanna-kruppe Nov 18, 2016 •

edited

Loading

shepmaster Nov 18, 2016

hanna-kruppe Nov 18, 2016 •

edited

Loading

shepmaster Nov 18, 2016

hanna-kruppe Nov 18, 2016

michaelwoerister commented Nov 18, 2016

shepmaster commented Nov 18, 2016 •

edited

Loading

shepmaster commented Nov 18, 2016

michaelwoerister commented Nov 18, 2016

shepmaster commented Nov 18, 2016 •

edited

Loading

sanxiyn commented Nov 21, 2016

shepmaster commented Dec 1, 2016

shepmaster commented Dec 1, 2016

michaelwoerister left a comment

michaelwoerister Dec 2, 2016

shepmaster Dec 3, 2016

michaelwoerister Dec 2, 2016

shepmaster Dec 2, 2016

shepmaster Dec 2, 2016

michaelwoerister Dec 2, 2016

shepmaster Dec 3, 2016

michaelwoerister commented Dec 3, 2016

bors commented Dec 3, 2016

bors commented Dec 4, 2016

shepmaster commented Dec 4, 2016

bors commented Dec 4, 2016

[LLVM 4.0] Handle new DIFlags enum #37857

[LLVM 4.0] Handle new DIFlags enum #37857

Conversation

shepmaster commented Nov 18, 2016

rust-highfive commented Nov 18, 2016

shepmaster commented Nov 18, 2016

alexcrichton commented Nov 18, 2016

hanna-kruppe Nov 18, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanna-kruppe Nov 18, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanna-kruppe Nov 18, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelwoerister commented Nov 18, 2016

shepmaster commented Nov 18, 2016 • edited Loading

shepmaster commented Nov 18, 2016

michaelwoerister commented Nov 18, 2016

shepmaster commented Nov 18, 2016 • edited Loading

sanxiyn commented Nov 21, 2016

shepmaster commented Dec 1, 2016

shepmaster commented Dec 1, 2016

michaelwoerister left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelwoerister commented Dec 3, 2016

bors commented Dec 3, 2016

bors commented Dec 4, 2016

shepmaster commented Dec 4, 2016

bors commented Dec 4, 2016

hanna-kruppe Nov 18, 2016 •

edited

Loading

hanna-kruppe Nov 18, 2016 •

edited

Loading

hanna-kruppe Nov 18, 2016 •

edited

Loading

shepmaster commented Nov 18, 2016 •

edited

Loading

shepmaster commented Nov 18, 2016 •

edited

Loading