Use Clang's feature-detection macros for feature testing, not its "marketing" version numbers

RESOLVED FIXED in mozilla11

Status

()

Core
MFBT
--
minor
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Waldo, Assigned: Waldo)

Tracking

unspecified
mozilla11
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 582471 [details] [diff] [review]
Patch

Skimming Clang mailing list traffic tonight, I discovered that vendors are seemingly intent on muddying the waters by disconnecting Clang version numbers from feature sets -- good times.  So relying on version checks for features is a bit dodgy.  Conveniently Clang provides feature detection macros which will do the same work, arguably more clearly.  Whee, kinda-make-work.

The warning about version checking is here, for the major/minor macros:

http://clang.llvm.org/docs/LanguageExtensions.html#builtinmacros

The patch uses the __has_extension macro because we want to use the relevant language features even if we're not compiling plain old C++98 -- no reason to hold back use of these features for a full transition over.  __has_extension is documented here:

http://clang.llvm.org/docs/LanguageExtensions.html#__has_feature_extension

The arguments passed to __has_extension are documented here:

http://clang.llvm.org/docs/LanguageExtensions.html#cxx_deleted_functions
http://clang.llvm.org/docs/LanguageExtensions.html#cxx_override_control

I checked some .i files with this patch, and things translate as expected in a Clang compile.
Attachment #582471 - Flags: review?(jones.chris.g)
Component: General → MFBT
QA Contact: general → mfbt
Attachment #582471 - Flags: review?(jones.chris.g) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/87be07cf8c10
Target Milestone: --- → mozilla11
https://hg.mozilla.org/mozilla-central/rev/87be07cf8c10
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.