[PATCH] D127462: [Clang] Begin implementing Plan 9 C extensions

[Keegan Saunders via Phabricator via cfe-commits]

ksaunders added a comment.

> Just to check -- do you think (some of) these features are something you wish to propose to WG14 for adoption into C? e.g., are you aiming to get multiple compilers to implement Plan 9 extensions to demonstrate to WG14 that this is existing practice in C compilers?

A lot of the Plan 9 extensions were actually adopted by C99 like compound literals and anonymous structures. Although I find these additional extensions interesting and useful, I don't think that they belong in C and they should remain as non-standard extensions. My interests lie in compiling existing code with Clang which utilizes these extensions, rather than encouraging new code to utilize them.

There was actually a proposal to add Plan 9 extensions into the Linux kernel, but Linus rejected it. I personally share his opinion that the silent type conversion that the Plan 9 compilers introduce can be problematic. But on the other hand, they are also very powerful when used judiciously. It's on the LKML here if you're interested: https://lkml.org/lkml/2019/1/9/1127

> Does this work for accessing r->FirstLock but give an ambiguous lookup for r->hold? Or do you only allow one member of the underlying canonical type?

Good question. The compilers only allow one member of the underlying type. So you'll get an error saying you've declared `Lock` twice.

> Also, why does it require a typedef name?

I am not sure, but I presume it is because of cases like this:

  struct A
  {
      int a;
  };
  
  struct B
  {
      int b;
  };
  
  typedef struct B A;
  
  struct Example
  {
      struct A;
      A;
  };

So it's not clear when you do `example->A` which member you are referring to. If you restrict it to typedef names then you have no ambiguity of this kind.

> Ah, interesting. So this is another case where multiple members of the same type would be a problem. Does this only find structure/union members, or does this also work for other members? e.g. void size(size_t *) being called with lock(r)? And if it works for other members... what does it do for bit-field members which share an allocation unit?

It only searches for //unnamed// structure and union members, so non-record members like bit-fields are not used for resolution. That's a good test case I should add as well, yeah.

> Thanks for the extra details!

Thank you for your interest :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127462