[PATCH] Initial support for __sptr and __uptr

[Richard Smith]

You have ''__foo'' in some of your diagnostics. These should only use a
single level of quotes.

Should these really be handled as declaration attributes? They look like
they would more naturally be type attributes. Can you do this:

  void * __sptr * __uptr p;

I don't think there's any need to check MicrosoftExt in SemaDeclAttr: these
things are only keyword in MicrosoftExt mode.

+    // You cannot have both __sptr and __uptr on the same declaration, nor
can
+    // you duplicate the attributes.
+    bool HasUPtr = D->hasAttr<UPtrAttr>(), HasSPtr =
D->hasAttr<SPtrAttr>();
+    if ((HasUPtr && Kind == AttributeList::AT_SPtr) ||
+        (HasSPtr && Kind == AttributeList::AT_UPtr)) {
+      S.Diag(Attr.getLoc(), diag::err_attributes_are_not_compatible)
+        << S.Context.Idents.get("'__sptr'").getName()
+        << S.Context.Idents.get("'__uptr'").getName();

This seems like a very strange way to convert a string literal into a
StringRef.

On Mon, May 13, 2013 at 5:37 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> __sptr and __uptr are pointer type qualifiers that relate to __ptr32
> and __ptr64.  Specifically, they specify how pointers are supposed to
> be converted (sign extended or zero extended).  For more information,
> see MSDN: http://msdn.microsoft.com/en-us/library/aa983399.aspx
>
> This patch brings in parsing support, some semantic warnings and test
> cases for code which uses __sptr and __uptr in conjunction with
> __ptr32 and __ptr64.  A future patch will have to be made to hook into
> the codegen machinery to support __ptr32 and __ptr64 more fully.
>
> This patch is modeled after the existing __ptr32 and __ptr64 support.
>
> ~Aaron
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130513/00921d23/attachment.html>