[PATCH] D123167: [HLSL] Pointers are unsupported in HLSL

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D123167#3434289 <https://reviews.llvm.org/D123167#3434289>, @beanz wrote:

> In D123167#3434023 <https://reviews.llvm.org/D123167#3434023>, @aaron.ballman wrote:
>
>> I think you're going to need semantic restrictions as well as parsing restrictions because of type deduction. Even if you don't support templates (yet), there's still `auto`, `decltype`, `__typeof__`, and `__auto_type` (I probably missed some, lol) to worry about.
>
> Thankfully HLSL is like C++98-based... I don't think we support any of those cases.

Oh, were compilers that easy... https://godbolt.org/z/EMasKrdh3

>> Also... can HLSL be combined with Objective-C mode (do we have to worry about their pointers as well)?
>
> Oh god... Now you're giving me nightmares. I feel like implementing objc_msgsend on a GPU might be a bridge (or ten) too far...

Heh, good. Can you make sure we reject that situation loudly in the frontend (in another patch, on another day, no rush)?



================
Comment at: clang/test/ParserHLSL/parse_pointer.hlsl:23
+  return F->X;
+}
----------------
beanz wrote:
> aaron.ballman wrote:
> > Here are a few more fun test cases (which may require semantic tests instead of parsing tests):
> > ```
> > void func();
> > 
> > void devilish_language(auto look_ma_no_pointers); // templates get you the same effects as well
> > 
> > void test() {
> >   int x;
> >   devilish_language(&x); // I presume we want this to be diagnosed
> >   devilish_language(func); // I think you wanted this to not be diagnosed?
> >   devilish_language("oh no, not array decay!"); // Same here as function decay?
> > 
> >   auto but_but_but = "please, stop Aaron!" + 0; // Uhhh... is the addition okay but the declaration bad?
> > 
> >   int array[2];
> >   *(&array[0] + 1) = 12; // Maaaayybbbe this is fine?
> > }
> > ```
> > (Thing for you to double-check: do any targets predefine macros that expand to a pointer? I checked InitPreprocessor.cpp and things looked fine there, but I didn't check targets.)
> I am in awe of your gift for finding ways to trip things up :)
> 
> I think most of these we can't hit because of `auto`. Eyeballing that lat case we _might_ handle it. I'll double check.
I am broken for writing decent code after spending so many years in Core thinking about edge cases. :-D

Btw, here's another one to try:
```
int i = *(int *)0; // Check that pointer types used in expressions are caught, same for reference
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123167/new/

https://reviews.llvm.org/D123167