compnerd closed this revision.
compnerd added a comment.
SVN r324701
Repository:
rC Clang
https://reviews.llvm.org/D42614
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
In https://reviews.llvm.org/D42614#1001279, @compnerd wrote:
> @rjmccall, I've updated the approach and no longer abuse the existing
> decoration styles. This uses a custom namespace with
compnerd added a comment.
@rjmccall, I've updated the approach and no longer abuse the existing
decoration styles. This uses a custom namespace with artificial types to
differentiate the types. I've also ensured that the parameter types do not
encode the type information.
Repository:
rC C
compnerd updated this revision to Diff 133319.
compnerd edited the summary of this revision.
compnerd added a comment.
Address comments from @rjmccall
Repository:
rC Clang
https://reviews.llvm.org/D42614
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenObjCXX/msabi-objc-extensions.mm
tes
compnerd added a comment.
Yeah, Im afraid I cannot definitely say that will never be sensible. I think I
would, in fact, prefer an alternative. I'm just not sure what is a good viable
alternative, especially since we are constrained in what the grammar accepts.
The desugaring of the `id` and
rjmccall added a comment.
In https://reviews.llvm.org/D42614#990808, @compnerd wrote:
> Hmm, the only thing that we could fake would be namespaces on the parameter
> types. Is that better? I'm not tied to re-using the existing mangling.
I'm just worried about re-using the existing mangling c
compnerd added a comment.
Hmm, the only thing that we could fake would be namespaces on the parameter
types. Is that better? I'm not tied to re-using the existing mangling.
Repository:
rC Clang
https://reviews.llvm.org/D42614
___
cfe-commits m
rjmccall added a comment.
It's not just that functions can't be overloaded on the parameter-variable type
qualifier — it's not part of the function type at all, just like making a
parameter 'const int' instead of 'int' is not part of the function type. I
understand that MSVC mangles some thing
smeenai added a comment.
pin_ptr is technically not supposed to appear as a function parameter, and
having it in that position can screw up demangling. Considering __strong is the
default, it's probably not a good idea to map that one to pin_ptr; whichever
qualifier is least likely to appear as
compnerd created this revision.
compnerd added a reviewer: rjmccall.
Herald added a subscriber: cfe-commits.
Add support for Objective C lifetime qualifiers in MS ABI. Because
there is no formal way to add a custom extension on a pointer qualifier,
re-use C++/CX (which is deprecated) and C++/CLI
10 matches
Mail list logo