Page MenuHomePhabricator

smeenai (Shoaib Meenai)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 19 2016, 10:21 AM (121 w, 4 d)

Recent Activity

Wed, Dec 12

smeenai added inline comments to D55606: [gn build] Add infrastructure to create symlinks and use it to create lld's symlinks.
Wed, Dec 12, 5:04 PM
smeenai added a comment to D55624: Windows rename_internal function incorrectly passing character count instead of byte count to SetFileInformationByHandle..

Committed in r348995. (I also took the liberty of adding a [Support] tag to the title and wrapping the commit message, in line with LLVM conventions; see https://llvm.org/docs/DeveloperPolicy.html#commit-messages). Thanks for the patch!

Wed, Dec 12, 4:13 PM
smeenai committed rL348995: [Support] Fix FileNameLength passed to SetFileInformationByHandle.
[Support] Fix FileNameLength passed to SetFileInformationByHandle
Wed, Dec 12, 4:11 PM
smeenai closed D55624: Windows rename_internal function incorrectly passing character count instead of byte count to SetFileInformationByHandle..
Wed, Dec 12, 4:11 PM
smeenai committed rL348993: [gn build] Fix defines define on Windows.
[gn build] Fix defines define on Windows
Wed, Dec 12, 4:03 PM
smeenai closed D55617: [gn build] Fix defines define on Windows.
Wed, Dec 12, 4:03 PM
smeenai accepted D55624: Windows rename_internal function incorrectly passing character count instead of byte count to SetFileInformationByHandle..

That's the intent ... it uploads the entire file to Phabricator, so that it can be viewed through the web interface. The arcanist tool does that for you automatically, as an alternative to have to copy and paste a giant block of text around.

Wed, Dec 12, 3:56 PM
smeenai added reviewers for D55624: Windows rename_internal function incorrectly passing character count instead of byte count to SetFileInformationByHandle.: compnerd, rnk.

This LGTM, but before I approve, I'd like to look around the surrounding code to confirm things are how I expect, but this patch is uploaded without context :( Could you reupload with context? See https://llvm.org/docs/Phabricator.html (the part about using -U999999 in your git commands to generate full context).

Wed, Dec 12, 3:22 PM
smeenai added a comment to D55606: [gn build] Add infrastructure to create symlinks and use it to create lld's symlinks.

https://reviews.llvm.org/D55617

Wed, Dec 12, 2:18 PM
smeenai created D55617: [gn build] Fix defines define on Windows.
Wed, Dec 12, 2:03 PM
smeenai added a comment to D55606: [gn build] Add infrastructure to create symlinks and use it to create lld's symlinks.

I started playing with this:

Wed, Dec 12, 1:20 PM
smeenai added inline comments to D55606: [gn build] Add infrastructure to create symlinks and use it to create lld's symlinks.
Wed, Dec 12, 12:23 PM
smeenai added inline comments to D55606: [gn build] Add infrastructure to create symlinks and use it to create lld's symlinks.
Wed, Dec 12, 11:43 AM
smeenai added inline comments to D55606: [gn build] Add infrastructure to create symlinks and use it to create lld's symlinks.
Wed, Dec 12, 11:20 AM

Tue, Dec 11

smeenai added a reviewer for D55503: Change llvm call once check for building Swift for PowerPC(ppc64le): compnerd.
Tue, Dec 11, 10:25 PM
smeenai abandoned D44619: [CodeGen] Add cleanup scope to EmitInlinedInheritingCXXConstructorCall.

https://reviews.llvm.org/D55543 does the same thing

Tue, Dec 11, 10:19 PM
smeenai added a comment to D55543: [CodeGen] Fix assertion on throwing object with inlined inherited constructor and non-trivial destructor..

I'd tried this exact same patch back in https://reviews.llvm.org/D44619, but I was running into a bunch of check-clang failures with it, and I was never able to figure them out. It looks like it works now though, so I'm glad :) Richard's comment from that diff might still be relevant:

Tue, Dec 11, 10:19 PM

Mon, Dec 3

smeenai committed rL348217: [projects] Use directory name for add_llvm_external_projects.
[projects] Use directory name for add_llvm_external_projects
Mon, Dec 3, 4:15 PM
smeenai committed rL348180: [cmake] Clean up add_llvm_subdirectory.
[cmake] Clean up add_llvm_subdirectory
Mon, Dec 3, 12:08 PM
smeenai closed D55104: [cmake] Clean up add_llvm_subdirectory.
Mon, Dec 3, 12:08 PM
smeenai added a reviewer for D55104: [cmake] Clean up add_llvm_subdirectory: compnerd.
Mon, Dec 3, 12:00 PM

Fri, Nov 30

smeenai committed rL348064: [projects] Use add_llvm_external_project for implicit projects.
[projects] Use add_llvm_external_project for implicit projects
Fri, Nov 30, 5:44 PM
smeenai closed D55105: [projects] Use add_llvm_external_project for implicit projects.
Fri, Nov 30, 5:44 PM

Thu, Nov 29

smeenai updated the diff for D55105: [projects] Use add_llvm_external_project for implicit projects.

Testing

Thu, Nov 29, 10:48 PM
smeenai updated the diff for D55105: [projects] Use add_llvm_external_project for implicit projects.

Correct patch

Thu, Nov 29, 10:46 PM
smeenai created D55105: [projects] Use add_llvm_external_project for implicit projects.
Thu, Nov 29, 10:45 PM
smeenai created D55104: [cmake] Clean up add_llvm_subdirectory.
Thu, Nov 29, 10:42 PM
smeenai committed rL347937: [CMake] build correctly if build path contains whitespace.
[CMake] build correctly if build path contains whitespace
Thu, Nov 29, 4:33 PM
smeenai closed D55081: [CMake] build correctly if build path contains whitespace (https://bugs.llvm.org/show_bug.cgi?id=39843).
Thu, Nov 29, 4:33 PM
smeenai accepted D55081: [CMake] build correctly if build path contains whitespace (https://bugs.llvm.org/show_bug.cgi?id=39843).

Straightforward fix, so LGTM.

Thu, Nov 29, 3:01 PM

Wed, Nov 21

smeenai added a reviewer for D53696: [Haiku] Support __float128 for Haiku x86 and x86_64: compnerd.
Wed, Nov 21, 4:43 PM · Restricted Project

Nov 15 2018

smeenai planned changes to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.

Hmm, but don't we want it to affect all components? For example, consider something like:

@interface I
@end

template <class T> class C {};

void f();
void g() {
  try {
    f();
  } catch (C<I> *) {
  }
}

I would say that we want the RTTI for C<I> * to have the discriminator for I.

Why? IIUC, you're adding the discriminator to distinguish between two different RTTI objects. It's not like there are two different types. You should mangle C<I> normally here.

Nov 15 2018, 1:43 PM
smeenai added a comment to D54595: [libcxx] Fix libc++ re-exporting logic when Command Line Tools are not installed.

check-cxx-abilist passes for me with this applied (Mojave, Xcode 10.1).

Nov 15 2018, 1:30 PM

Nov 14 2018

smeenai committed rL346882: [AST] Fix typo in MicrosoftMangle.
[AST] Fix typo in MicrosoftMangle
Nov 14 2018, 11:19 AM
smeenai committed rC346882: [AST] Fix typo in MicrosoftMangle.
[AST] Fix typo in MicrosoftMangle
Nov 14 2018, 11:19 AM
smeenai closed D54536: [AST] Fix typo in MicrosoftMangle.
Nov 14 2018, 11:19 AM
smeenai created D54536: [AST] Fix typo in MicrosoftMangle.
Nov 14 2018, 10:33 AM

Nov 13 2018

smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.

Nov 13 2018, 5:35 PM
smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

@rnk pointed out on IRC that the MicrosoftCXXNameMangler is actually specifically designed to manage the mangling of only a single name, in which case adding state to it for handling RTTI seems like a natural approach. @rjmccall, what do you think? I think this is much cleaner than having to thread through the RTTI state to every individual method. The ForRTTI_t enum is modeled after the ForDefinition_t enum used in CGM, but I'm happy to switch to a more general struct (as you'd mentioned before) if you prefer.

Nov 13 2018, 4:53 PM
smeenai updated the diff for D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

Stateful approach

Nov 13 2018, 4:48 PM
smeenai accepted D54499: [codeview] Make "clang -g" emit codeview by default when targetting MSVC.

LGTM, though you may wanna also wait for Zach.

Nov 13 2018, 4:32 PM

Nov 9 2018

smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

@rjmccall I prototyped the ForRTTI parameter approach in D53546. It could definitely be cleaned up a bit, but it demonstrates the problems I saw with the added parameter. Namely, mangleType(QualType, SourceRange, QualifierMangleMode) has a bunch of additional logic which is needed for correctness, so we need to thread the parameter through the entire chain, and the only way I could think of doing that without adding the parameter to every single mangleType overload was to have an additional switch to dispatch to the overloads with the added ForRTTI parameter, which is pretty ugly.

As I see it, there are a few ways to proceed here:

  • The approach in D53546 (cleaned up a bit). I think it's pretty ugly, but you may have suggestions on how to do it better.
  • In the mangleType overload for ObjCObjectPointerType, skipping the generic mangleType dispatch and going directly to either the ObjCObjectType or ObjCInterfaceType overloads. That avoids the ugliness in the generic mangleType, but it also requires us to duplicate some logic from it in the ObjCObjectPointerType overload, which doesn't seem great either.
  • Maintaining ForRTTI state in the mangler instead of threading a parameter through (I'm generally not a fan of state like that, but it might be cleaner than the threading in this case?)
  • Just sticking with what I'm doing in this patch.

    What do you think?

Sorry for the delay. I think duplicating the dispatch logic for ObjCObjectPointerType is probably the best approach; the pointee type will always an ObjCObjectType of some sort, and there are only two kinds of those.

Sorry, I'm still not sure how this will work.

Duplicating the dispatch logic for ObjCObjectPointerType ends up looking like P8114, which is fine. However, when we're actually mangling RTTI or RTTI names, we're still going through the main mangleType(QualType, SourceRange, QualifierMangleMode) overload, which still requires us to thread ForRTTI through that function, which still requires us to duplicate the switch in that function (to handle the ForRTTI case, since the other switch is generated via TypeNodes.def and not easily modifiable), which is the main ugliness in my opinion. Do you also want me to add special dispatching to mangleCXXRTTI and mangleCXXRTTIName to just call the ObjCObjectPointerType function directly when they're dealing with that type? That's certainly doable, but at that point just keeping some state around in the demangler starts to feel cleaner, at least to me.

Well, you could check for an ObjCObjectPointerType in the top-level routine.

But yeah, probably the cleanest thing to do would to be push the state through the main dispatch. Don't push a single bool through, though; make a TypeManglingOptions struct to encapsulate it, in case we have a similar problem elsewhere. It should have a method for getting options that should be propagated down to component type manglings, and that method can drop the "for RTTI" bit; that's the part that ObjCObjectPointerType can handle differently.

Nov 9 2018, 11:33 AM

Nov 8 2018

smeenai added a comment to D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

From the summary,

"In ELF, symbols non-weak symbols"

The first "symbols" seems extraneous?

I fixed it in the commit message, but Phabricator seems to showing the commit message from the first patch. I'll manually update the summary.

Nov 8 2018, 11:11 AM
smeenai added a comment to D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

From the summary,

Nov 8 2018, 11:07 AM

Nov 7 2018

smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

Sorry, had a leftover draft which I forgot to clean up. Edited in Phabricator now.

Nov 7 2018, 7:10 PM
smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

@rjmccall I prototyped the ForRTTI parameter approach in D53546. It could definitely be cleaned up a bit, but it demonstrates the problems I saw with the added parameter. Namely, mangleType(QualType, SourceRange, QualifierMangleMode) has a bunch of additional logic which is needed for correctness, so we need to thread the parameter through the entire chain, and the only way I could think of doing that without adding the parameter to every single mangleType overload was to have an additional switch to dispatch to the overloads with the added ForRTTI parameter, which is pretty ugly.

As I see it, there are a few ways to proceed here:

  • The approach in D53546 (cleaned up a bit). I think it's pretty ugly, but you may have suggestions on how to do it better.
  • In the mangleType overload for ObjCObjectPointerType, skipping the generic mangleType dispatch and going directly to either the ObjCObjectType or ObjCInterfaceType overloads. That avoids the ugliness in the generic mangleType, but it also requires us to duplicate some logic from it in the ObjCObjectPointerType overload, which doesn't seem great either.
  • Maintaining ForRTTI state in the mangler instead of threading a parameter through (I'm generally not a fan of state like that, but it might be cleaner than the threading in this case?)
  • Just sticking with what I'm doing in this patch.

    What do you think?

Sorry for the delay. I think duplicating the dispatch logic for ObjCObjectPointerType is probably the best approach; the pointee type will always an ObjCObjectType of some sort, and there are only two kinds of those.

Nov 7 2018, 7:00 PM
smeenai committed rC346378: [clang] Set CMP0075 to new.
[clang] Set CMP0075 to new
Nov 7 2018, 4:34 PM
smeenai committed rL346378: [clang] Set CMP0075 to new.
[clang] Set CMP0075 to new
Nov 7 2018, 4:32 PM
smeenai committed rL346377: [cmake] Set CMP0075 to NEW.
[cmake] Set CMP0075 to NEW
Nov 7 2018, 4:20 PM
smeenai closed D54236: [cmake] Set CMP0075 to NEW.
Nov 7 2018, 4:20 PM
smeenai added a comment to D54236: [cmake] Set CMP0075 to NEW.

That's fair. I can just change the policy for clang explicitly in a separate diff then.

Nov 7 2018, 4:12 PM
smeenai added a comment to D54236: [cmake] Set CMP0075 to NEW.

Somewhat orthogonal to this diff, but should we change clang so that it only does its own cmake_minimum_required call when it's being built standalone? There's potential for inconsistent policies between building clang in-tree and standalone if we do that, but it also seems strange to just wholesale ignore LLVM's policy settings.

Nov 7 2018, 3:46 PM
smeenai created D54236: [cmake] Set CMP0075 to NEW.
Nov 7 2018, 3:46 PM

Nov 6 2018

smeenai committed rL346290: [cmake] Fix typo. NFC.
[cmake] Fix typo. NFC
Nov 6 2018, 6:25 PM

Nov 5 2018

smeenai resigned from D48798: llvm-nm: Observe -no-llvm-bc for archive members.

I'm not familiar enough with this part of the code to feel comfortable accepting, sorry.

Nov 5 2018, 11:08 AM

Nov 2 2018

smeenai added a comment to D53598: Add docs+a script for building clang/LLVM with PGO.

I notice that you're using LLVM_BUILD_INSTRUMENTED=IR, which corresponds to -fprofile-generate (IR-level profiling), instead of -fprofile-instr-generate (clang-level profiling). Did you play around with both and observe that IR-level profiling gave you better results?

Nov 2 2018, 3:19 PM

Oct 31 2018

smeenai added a comment to D53598: Add docs+a script for building clang/LLVM with PGO.

LLVM's CMake has built in support for PGO; see https://llvm.org/docs/AdvancedBuilds.html#multi-stage-pgo. I haven't looked at the script in detail, but does it function similarly?

Oct 31 2018, 1:54 PM
smeenai committed rL345711: [lldb] Fix race condition in framework installation.
[lldb] Fix race condition in framework installation
Oct 31 2018, 3:43 AM
smeenai committed rLLDB345711: [lldb] Fix race condition in framework installation.
[lldb] Fix race condition in framework installation
Oct 31 2018, 3:43 AM
smeenai closed D53917: [lldb] Fix race condition in framework installation.
Oct 31 2018, 3:43 AM

Oct 30 2018

smeenai created D53917: [lldb] Fix race condition in framework installation.
Oct 30 2018, 6:04 PM
smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

Ping @rjmccall. Let me know if the approach in D53546 is what you'd been envisioning, or if I'm just doing something completely brain-dead :)

Oct 30 2018, 4:14 PM
smeenai added inline comments to D53879: Make libc++'s versioning namespace customizable.
Oct 30 2018, 2:10 PM
smeenai added a comment to D53879: Make libc++'s versioning namespace customizable.

Awesome, I don't have to maintain an internal patch for this anymore :)

Oct 30 2018, 12:08 PM

Oct 25 2018

smeenai updated subscribers of D53051: [llvm-tapi] initial commit, supports ELF text stubs.
Oct 25 2018, 4:42 PM

Oct 23 2018

smeenai added inline comments to D53408: [PPC64] Long branch thunks. .
Oct 23 2018, 2:10 PM · lld

Oct 22 2018

smeenai committed rL344986: [ELF] Split up emulation.s per backend.
[ELF] Split up emulation.s per backend
Oct 22 2018, 6:21 PM
smeenai committed rLLD344986: [ELF] Split up emulation.s per backend.
[ELF] Split up emulation.s per backend
Oct 22 2018, 6:21 PM
smeenai closed D53544: [ELF] Split up emulation.s per backend.
Oct 22 2018, 6:21 PM
smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

@rjmccall I prototyped the ForRTTI parameter approach in D53546. It could definitely be cleaned up a bit, but it demonstrates the problems I saw with the added parameter. Namely, mangleType(QualType, SourceRange, QualifierMangleMode) has a bunch of additional logic which is needed for correctness, so we need to thread the parameter through the entire chain, and the only way I could think of doing that without adding the parameter to every single mangleType overload was to have an additional switch to dispatch to the overloads with the added ForRTTI parameter, which is pretty ugly.

Oct 22 2018, 6:20 PM
smeenai created D53546: [WIP][private] Add Obj-C discriminator to MS ABI RTTI.
Oct 22 2018, 6:11 PM
smeenai planned changes to D53546: [WIP][private] Add Obj-C discriminator to MS ABI RTTI.
Oct 22 2018, 6:11 PM
smeenai created D53544: [ELF] Split up emulation.s per backend.
Oct 22 2018, 5:47 PM
smeenai committed rL344984: [ELF] Actually fix test from r344976.
[ELF] Actually fix test from r344976
Oct 22 2018, 5:37 PM
smeenai committed rLLD344984: [ELF] Actually fix test from r344976.
[ELF] Actually fix test from r344976
Oct 22 2018, 5:36 PM
smeenai committed rL344980: [ELF] Fix test from r344976.
[ELF] Fix test from r344976
Oct 22 2018, 5:29 PM
smeenai committed rLLD344980: [ELF] Fix test from r344976.
[ELF] Fix test from r344976
Oct 22 2018, 5:29 PM
smeenai committed rL344976: [ELF] Handle elf32-littlearm in OUTPUT_FORMAT.
[ELF] Handle elf32-littlearm in OUTPUT_FORMAT
Oct 22 2018, 4:58 PM
smeenai committed rLLD344976: [ELF] Handle elf32-littlearm in OUTPUT_FORMAT.
[ELF] Handle elf32-littlearm in OUTPUT_FORMAT
Oct 22 2018, 4:58 PM
smeenai closed D53539: [ELF] Handle elf32-littlearm in OUTPUT_FORMAT.
Oct 22 2018, 4:58 PM
smeenai created D53539: [ELF] Handle elf32-littlearm in OUTPUT_FORMAT.
Oct 22 2018, 4:46 PM

Oct 19 2018

smeenai added a comment to D46228: [ELF] Use union-find set in Call-Chain Clustering (C³) heuristic to improve worst-case time complexity..

Do you have real world performance numbers (both time and memory) for this? Computational complexity isn't always the best predictor of actual performance because of e.g. cache characteristics (as @Bigcheese mentioned).

Oct 19 2018, 11:36 AM

Oct 9 2018

smeenai added inline comments to D53031: Expand comment for MinGW driver..
Oct 9 2018, 11:43 AM
smeenai added inline comments to D53031: Expand comment for MinGW driver..
Oct 9 2018, 11:18 AM

Oct 8 2018

smeenai added inline comments to D52990: [MinGW] Fix passing a sanitizer lib name as dependent lib.
Oct 8 2018, 3:04 PM
smeenai added inline comments to D52990: [MinGW] Fix passing a sanitizer lib name as dependent lib.
Oct 8 2018, 2:30 PM

Oct 4 2018

smeenai committed rL343832: [cmake] Also create lowercase extension WinSDK symlinks.
[cmake] Also create lowercase extension WinSDK symlinks
Oct 4 2018, 5:10 PM
smeenai added a comment to D52674: [AST] Add Obj-C discriminator to MS ABI RTTI.

Actually, I take that back ... I just misread the stack trace.

There are a bunch of hops between the mangleCXXRTTI call and the ultimate mangling function:

MicrosoftMangleContextImpl::mangleCXXRTTI(QualType, raw_ostream &)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectPointerType *, Qualifiers, SourceRange)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *, Qualifiers, SourceRange)

(the last one will be ObjCInterfaceType instead of ObjCObjectType if catching anything other than id)

Threading a ForRTTI flag or similar all the way to the final call seems pretty tricky. I can add an optional paramater to mangleType(QualType, SourceRange, QualifierMangleMode), but that function uses a generated switch case to call the specific mangleType functions, and I don't know how to special-case certain types in that switch case (to pass the extra parameter along) without doing something super ugly. Adding the extra parameter to every single mangleType overload seems highly non-ideal, which is why I was thinking of maintaining some internal state instead.

Well, that's why I was talking about how the pointee type of an ObjCObjectPointerType is always an ObjCObjectType (of which ObjCInterfaceType is a subclass) — the implication being that you don't actually have to do the switch to dispatch to one of those two cases.

Oct 4 2018, 3:03 PM
smeenai added inline comments to D52908: [LLD] [docs] Mention some notable feature in the release notes.
Oct 4 2018, 2:35 PM
smeenai committed rL343808: [AST] Revert mangling changes from r339428.
[AST] Revert mangling changes from r339428
Oct 4 2018, 12:52 PM
smeenai committed rC343808: [AST] Revert mangling changes from r339428.
[AST] Revert mangling changes from r339428
Oct 4 2018, 12:51 PM
smeenai closed D52581: [AST] Revert mangling changes from r339428.
Oct 4 2018, 12:51 PM

Oct 3 2018

smeenai added a comment to D52662: [libc++] Make sure we can build libc++ with -fvisibility=hidden.

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

The problem is that it requires applying the attribute to the class template itself as opposed to a single instantiation of it. Unless I am wrong?

Thinking about this more, I guess you can't really have a key function for a class template anyway, since you need to define all your methods inline for clients to be able to use your class.

You're right. I guess we _might_ be able to come up with a twisted way to achieve this with type_visibility, for example: declare (but not define) the key function in the template, then define it out-of-line, but add an explicit instantiation declaration of the key function for the specific instantiation of the class template we're interested in. And then apply the type_visibility("default") attribute to an explicit instantiation declaration of the instantiation of the class template we're interested in. IDK whether this would work, and I don't care. It's messy and too complicated, and this area of the language is already crazy enough.

Oct 3 2018, 5:40 PM
smeenai added a comment to D52662: [libc++] Make sure we can build libc++ with -fvisibility=hidden.

Hmm, why do we need to be able to explicitly instantiate vtables and RTTI ... doesn't the implied emission of those in the object file containing the key function work? I've been aware of a few -dev threads flying back and forth about various visibility issues for libc++, and I admit I haven't been keeping up with them fully, so I apologize if this has already been covered in one of those.

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

The problem is that it requires applying the attribute to the class template itself as opposed to a single instantiation of it. Unless I am wrong?

Oct 3 2018, 5:20 PM
smeenai committed rL343748: [ELF] Fix typo. NFC.
[ELF] Fix typo. NFC
Oct 3 2018, 5:12 PM
smeenai committed rLLD343748: [ELF] Fix typo. NFC.
[ELF] Fix typo. NFC
Oct 3 2018, 5:12 PM
smeenai committed rL343745: [ELF] Fix crash on invalid undefined local symbols.
[ELF] Fix crash on invalid undefined local symbols
Oct 3 2018, 4:55 PM
smeenai committed rLLD343745: [ELF] Fix crash on invalid undefined local symbols.
[ELF] Fix crash on invalid undefined local symbols
Oct 3 2018, 4:55 PM
smeenai closed D52815: [ELF] Fix crash on invalid undefined local symbols.
Oct 3 2018, 4:55 PM
smeenai closed D52815: [ELF] Fix crash on invalid undefined local symbols.
Oct 3 2018, 4:54 PM