[clang] [llvm] [llvm] Support llvm::Any across shared libraries on windows (PR #108051)

[Yitzhak Mandelbaum via cfe-commits]

ymand wrote:

> > What are the implications/requirements for users of DataflowAnalysis? Every instance specifices it's own lattice, which is converted to/from llvm::Any. Will every lattice definition require these new declarations?
> 
> If you think they will be used from external from the llvm library including by tests then yes. I wish i could just put the visibility attribute on the Any Id field its self, but windows uses two different attributes to import and export a symbol which causes issues when its used by different codebases that require it to be in a different state.

I see -- that's a bit of a problem. `DataflowAnalysis` is an abstraction, which in its implementation uses `llvm::Any`. Yet, IIUC, clients (who should be separated from any implementation details of the template) are now required to insert this (complex) formulation in their code. And, this is now viral -- any abstraction which seeks to wrap DataflowAnalysis and keep the Lattice type parameter will now also need to propagate this requirement to their users. And this same problem will hold for any template which uses llvm::Any in its implementation.

At the least, this requires very clear documentation -- but even better would be if there's a way to hide this in the implementation somehow, rather than pushing it on the user. Can you think of anything that would abstract this? I'd even propose a macro, but that's not enough because of demands on the namespacing. This seems unfortunately incompatible with any sort of modularity. :(

Do you have reference to an Issue tracking this or, even better, an RFC to the clang (or llvm) community? I'd like to better understand the context to see if we (analysis owners) can think of a way to avoid this. I'll also see if we can rip llvm::Any out of our implementation to avoid this altogether.

https://github.com/llvm/llvm-project/pull/108051