[PATCH] D48807: Add llvm::Any

[Zachary Turner via Phabricator via llvm-commits]

zturner added a comment.

In https://reviews.llvm.org/D48807#1157663, @dblaikie wrote:

> > So we give back the user an event object that has as wide of a common interface as possible, but still doesn't prevent access to all of the bits.  The consumer of the common interface will be common code.  Code that wants to decide what to do after hitting a breakpoint probably doesn't need all this platform specific information.  It can just stop, look up line and symbol information based on the address, and report it to the user.  But in a system like this which has deep hooks into the OS, it will be very frequent that the code handling an event needs to do something completely different depending on the platform.  So we branch out into platform specific code, and in that platform specific code we know how to consume the platform specific event data.
>
> Sounds pretty much the same as what LLVM's codebase would use polymorphism for (& dyn_cast, dyn_cast if chains, or switch over the type+cast, etc) since its inception. Some common API & some specific stuff that certain consumers care about. Doesn't necessarily mean it's the right way to do it - but there's certainly a lot of precedent (admittedly implemented before something like Any was as commonly thought about in C++, maybe).
>
> Wouldn't mind hearing some other perspectives in here - I'm still a bit reticent, but happy enough to sign off (once the technical feedback is addressed) if you're really feeling it.


Yes, the `dyn_cast` stuff is a good analogy.  And it would be theoretically possible to do what I need with `dyn_cast` and a base class.  The reason I'm hesitant to go that route though and prefer `any` over this approach is because it would really explode the inheritance hierarchy.  For every event type you would need at least 1 subclass per platform.  Just for a simple trap event, you'd need `LinuxTrapEvent`, `BSDTrapEvent`, `Win32TrapEvent`, `Win64TrapEvent`, `WinWow6432TrapEvent`.  And ultimately each of these would just would probably just contain 1 or 2 trivially copyable fields that you got directly from an OS syscall.  So the only purpose of the subclass would be to wrap some structure, not really to provide any actual functionality.  At that point you're already skirting pretty close to `Any` anyway


https://reviews.llvm.org/D48807