This is an archive of the discontinued LLVM Phabricator instance.

Add -f[no-]declspec to control recognition of __declspec as a keyword
ClosedPublic

Authored by wristow on Sep 30 2015, 6:41 PM.

Details

Summary

In versions of clang prior to r238238, declspec was recognized as a
keyword in all modes. It was then changed to only be enabled when
Microsoft or Borland extensions were enabled (and for CUDA, as a
temporary measure). There is a desire to support
declspec in
Playstation code, and possibly other environments. This commit adds a
command-line switch to allow explicit enabling/disabling of the
recognition of __declspec as a keyword. Recognition is enabled by
default in Microsoft, Borland, CUDA and PS4 environments, and disabled
in all other environments.

This proposed change supersedes D11207. In D11207, it was proposed that a new language-dialect be added to Clang, to support extensions used in the Playstation environment. The primary motivation of that language-dialect was the recognition of declspec as a keyword. After consideration, it was suggested that adding a switch to independently control the recognition of declspec was an alternative to consider. See:

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150713/133310.html

As a result of that, this proposed change adds a switch to control the recognition of __declspec.

Can someone review, and if OK then commit this patch for me, please?

-Warren Ristow
SN Systems - Sony Computer Entertainment Group

Diff Detail

Event Timeline

wristow updated this revision to Diff 36171.Sep 30 2015, 6:41 PM
wristow retitled this revision from to Add -f[no-]declspec to control recognition of __declspec as a keyword.
wristow updated this object.
compnerd added inline comments.Sep 30 2015, 6:55 PM
include/clang/Basic/LangOptions.def
93

Im not sure I care for Microsoft here. This is an extension that is supported on more than one compiler suite. How about "Enable support for __declspec extension"?

include/clang/Driver/Options.td
520

Shouldn't these be DriverOptions, and CC1Options?

lib/Driver/Tools.cpp
4663

The Args.hasFlag will correctly give you the value (-fdeclspec -fno-declspec will be treated as -fno-declspec). In fact, doesn't your implementation make -fno-declspec take precedence?

Plus, you marked these as cc1options above, not driver options. These aren't technically available here.

rsmith added a subscriber: rsmith.Sep 30 2015, 8:49 PM
rsmith added inline comments.
include/clang/Basic/LangOptions.def
93

These strings are used in a diagnostic of the form "support for %0 is not enabled", so "__declspec" or "__declspec keyword" would be appropriate.

include/clang/Driver/Options.td
520

This should be in f_clang_Group, not f_Group.

lib/Driver/Tools.cpp
4663

The options are in the driver's Options.td and marked as CC1Option, so they're available in both the driver and cc1.

wristow added inline comments.Oct 1 2015, 2:41 PM
include/clang/Basic/LangOptions.def
93

I see. Then I'll change it to "__declspec keyword", to both remove the Microsoft reference and make it appropriate for the diagnostic formed from it.

include/clang/Driver/Options.td
520

I'll upload an updated patch shortly that takes care of this.

lib/Driver/Tools.cpp
4663

OK, then I'll leave them marked as CC1Option.

4663

Regarding the -fno-declspec taking precedence question, I think I've got it right, but I could have misunderstood something. There is a complication with this declspec-keyword recognition, in that in addition to it being enabled by default for PS4, it's implicitly enabled by default with any of -fms-compatibility, -fms-extensions and -fborland-extensions (and temporarily also for CUDA). My goal of -fno-declspec is that it should over-ride any implicit enabling of declspec. The implicit enabling was handled in cc1 itself (by inspecting values that depend on -fms-compatibility, -fms-extensions, -fborland-extensions, and CUDA). I left that being handled in cc1, although I considered collecting that information here in the driver, and passing a more elaborate expression as the 'Default' arg to hasFlag(), in which case I wouldn't have needed to explicitly push_back("-fno-declspec"). Anyway, with implicit enabling of declspec happening in cc1, it was easy to over-ride it by explicitly passing -fno-declspec through, iff that was the last -fdeclspec/-fno-declspec arg passed by the user. So that's what I'm doing on the line with the "// Explicitly disabling __declspec." comment (unless I've misunderstood, if -fno-declspec isn't the last one, we don't get to that line).

wristow updated this revision to Diff 36307.Oct 1 2015, 2:58 PM

Updated patch to change the Group of the diagnostic from f_Group to f_clang_Group, and to change the string associated with the LANGOPT definition of the flag. Also fixed a minor typo in a comment.

compnerd added inline comments.Oct 1 2015, 6:56 PM
lib/Driver/Tools.cpp
4663

@rsmith, so they are. I misread something and was thinking they were under CC1Options.td.

4663

Sure, but you are still giving -fno-declspec precedence over -fdeclspec. Consider -fno-declspec -fdeclspec. I think what you want is Args.getLastArg, not Args.hasArg.

wristow updated this revision to Diff 36373.Oct 2 2015, 10:18 AM

Added 4 new tests, the verify the last -fdeclspec/-fno-declspec wins, both in the context of -fms-extensions and without -fms-extensions.

wristow added inline comments.Oct 2 2015, 10:21 AM
lib/Driver/Tools.cpp
4663

But in the '-fno-declspec -fdeclspec' case, the 'if' clause "wins", and we never even reach the test of the 'else if' clause. As I said at the end of my previous comment, if -fno-declspec isn't the last one, we don't get to that line. That said, given the interaction with "implicit enabling" of declspec (via Microsoft, Borland, CUDA), it's a bit different than vanilla switch-handling. So I've updated the tests to explicitly have some checks for '-fno-declspec -fdeclspec' case (and the reverse, and for with and without -fms-extensions interacting).

compnerd accepted this revision.Oct 2 2015, 7:26 PM
compnerd edited edge metadata.
This revision is now accepted and ready to land.Oct 2 2015, 7:26 PM
compnerd closed this revision.Oct 4 2015, 10:53 AM

Committed as SVN r249279 (as per your request in the initial revision).