rjmccall added a comment. In https://reviews.llvm.org/D40508#938675, @sepavloff wrote:
> In https://reviews.llvm.org/D40508#938040, @rjmccall wrote: > > > My skepticism about the raw_ostream is not about the design of having a > > custom raw_ostream subclass, it's that that subclass could conceivably be > > re-used by some other client. It feels like it belongs as an internal hack > > in Clang absent some real evidence that someone else would use it. > > > This class can be helpful in various cases where string identifier must > persistently identify an object and memory consumption must be low. It may be: > > - Name mangling, > - Symbol obfuscation, > - More convenient replacement for `raw_sha1_ostream` (the latter produces > binary result, while `raw_abbrev_ostream` produces text), There's no requirement to persistently identify an object here. > - If we introduce an option that allows a user to specify how many symbols of > full type name are kept in abbreviated name, then `llvm-link` may see types > named as `foo<int>` and `2544896211ff669ed44dccd265f4c9163b340190`, if they > come from modules compiled with different options. To find out that these are > the same type, it must have access to the same machinery. The LLVM linking model does not actually depend on struct type names matching. My understanding is that, at best, it uses that as a heuristic for deciding whether to make an effort to unify two types, but it's not something that's ultimately supposed to impact IR semantics. If we needed IR type names to match reliably, we would use a mangled name, not a pretty-print. https://reviews.llvm.org/D40508 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
