sepavloff added a comment.

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),
- 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.



================
Comment at: lib/AST/TypePrinter.cpp:1532-1534
+namespace {
+template<typename TA>
+void printTo(raw_ostream &OS, ArrayRef<TA> Args, const PrintingPolicy &Policy,
----------------
rjmccall wrote:
> sepavloff wrote:
> > rnk wrote:
> > > `static` is nicer than a short anonymous namespace.
> > Yes, but this is function template. It won't create symbol in object file. 
> > Actually anonymous namespace has no effect here, it is only a documentation 
> > hint.
> Nonetheless, we generally prefer to use 'static' on internal functions, even 
> function templates, instead of putting them in anonymous namespaces.
OK, fixed in rL319290.


https://reviews.llvm.org/D40508



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to