[PATCH] D29868: Recover more gracefully when __declspec is not supported as a keyword

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: lib/Parse/ParseDecl.cpp:2973
+      // recognize that scenario and recover gracefully.
+      if (!getLangOpts().MicrosoftExt && Tok.is(tok::identifier) &&
+          Tok.getIdentifierInfo()->getName().equals("__declspec")) {
----------------
compnerd wrote:
> Shouldn't this be `getLangOpts().DeclSpecKeyword` since you don't need the Microsoft extensions as much as you need the declspec keyword to be processed.  Having `MicrosoftExt` implicitly enable `DeclSpecKeyword` (just as borland mode enables it as well).  I suppose that it would fail anyways as `Tok.is(tok::identifier)` would fail.
That's a good point, I've corrected.


================
Comment at: lib/Parse/ParseDecl.cpp:2989
+
+          Diag(Loc, diag::err_ms_attributes_not_enabled);
+          continue;
----------------
compnerd wrote:
> I think that we want to emit the diagnostic even if there is no parenthesis as `__declspec` is a reserved identifier, and we would normally diagnose the bad `__declspec` (expected '(' after '__declspec').
Yes, but it could also lead to a rejecting code that we used to accept and properly handle when __declspec is an identifier rather than a keyword. e.g.,
```
struct __declspec {};

__declspec some_func(void);
```
By looking for the paren, we run less risk of breaking working code, even if that code abuses the implementation namespace (after all, __declspec it not a keyword in this scenario).


https://reviews.llvm.org/D29868