cdefs.h: Start to modernize

[imp]

Summary

Anything that's in this file that starts with __ is private to the
FreeBSD tree, so remove the obsolete ones:
GNUCLIKE_ASM
GNUCLIKE_MATH_BUILTIN_CONSTANTS
GNUCLIKE_TYPEOF
GNUCLIKE_SECTION
GNUCLIKE_CTOR_SECTION_HANDLING
GNUCLIKE_BUILTIN_CONSTANT_P
GNUCLIKE_BUILTIN_VARARGS
GNUCLIKE_BUILTIN_STDARG
GNUCLIKE_BUILTIN_VAALIST
GNUC_VA_LIST_COMPATIBILITY
GNUCLIKE_BUILTIN_NEXT_ARG
GNUCLIKE_MATH_BUILTIN_RELOPS
GNUCLIKE_BUILTIN_MEMCPY
CC_SUPPORTS_INLINE
CC_SUPPORTS_INLINE
CC_SUPPORTS_INLINE__
CC_SUPPORTS_FUNC__
CC_SUPPORTS_WARNING
CC_SUPPORTS_VARADIC_XXX
__CC_SUPPORTS_DYNAMIC_ARRAY_INIT

Assume that the compiler we're using support gnuc constructs >= gcc 6,
so simplify ancient support there. Unifdef the above in the code since
they were always defined, but sys/cdefs.h is the only place that
remained. clang supports all these constructs for all interesting
versions of clang.

There are some __ symbols that may be in use by external software, so
don't retire const, etc for now. Unconditionally define some of
them. They might be used outside of the tree which might break the other
compiler (those that don't define GNUC__) support that works today. If
there's actaully any of these users out there, I'll cope.

Sponsored by: Netflix

Test Plan

It's my belief that all of the things that were made uncodnitional are only used in the FreeBSD tree, and so we can assume they will use a proper compiler. Lots of other places already assume that, so this shouldn't break anything. Will do a exp run though.

[imp]

exp run https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270249

Also, phab thinks all the __ above is markup.

[kib]

IMO this change should be done after we (as project) define two things: which compilers we intend to support, and which minimal version of them are. Then some place (perhaps cdefs.h) should check the requirements we put.

That said, I sometimes find it convenient to see where gcc features were introduced.

sys/sys/cdefs.h

129

Why removing GNUC_PREREQ? Even if we agree to remove all stuff from cdefs.h that you remove there, the macro is still useful because newer gcc versions add features not detectable by other means (or fix bugs).

In fact, it breaks build I believe: there are many consumers of the macro outside of sys/cdefs.h, as the quick grep confirms.

[imp]

In D39097#890235, @kib wrote:

IMO this change should be done after we (as project) define two things: which compilers we intend to support, and which minimal version of them are. Then some place (perhaps cdefs.h) should check the requirements we put.

I tend to agree... There's 'compilers to build the tree' and 'compilers to generate code using the published headers'. The former is easy (gcc 9 or newer is all that works, clang 12 or newer is all that works). The latter can get tricky because pcc has worked in the past (I'm not entirely sure it does now) and tcc worked in the further past, but hasn't worked in some time)... older gcc and older clang also work to build 'hello world' and other code, though I'm not sure how far back into the past we can support given some of the newer features that need linker support that wasn't present in the assembler/loader needed for some of these older compilers.

That said, I don't think that these changes break anything that wasn't already broken.

That said, I sometimes find it convenient to see where gcc features were introduced.

A lot of the features were an approximate version, and we've not been careful, at all, for versions > 4.2.3... So it's inaccurate at best at times... and also we've added some things unconditionally that weren't around in egcs 2.95... But finding the right docs can also be tricky, so I'm sympathetic to wanting to know this data... I'm just not sure that the project should be in the business of curating it after some amount of time that we've not been using the compilers.

sys/sys/cdefs.h

129

Yea, that was premature. I pushed the wrong patch here.

[imp]

put back GNU_PREREQ. It's stil needed

[kib]

I am curious what was the method to check that the patch is correct. Did you grepped for use of each removed symbol? Just building the patched sources is not enough.

sys/sys/cdefs.h

84–88

[imp]

In D39097#893327, @kib wrote:

I am curious what was the method to check that the patch is correct. Did you grepped for use of each removed symbol? Just building the patched sources is not enough.

I greped the entire tree for everything I removed (except for GNU_PREREQ). I didn't git -S to see where their last use was removed though.

I didn't remove __P() yet since I couldn't be sure it wasn't still used.

[imp]

comments and other nits from kib@
Remove some now-obsolete commnets.
Wish I could kill __P() :)

[kib]

sys/sys/cdefs.h

298

I understand why would you remove the comment above the this line, but IMO the check for c++ standard version should be kept as is. It is not about compiler, but about the standard compliance selection.

339

Are there situations where current compilers legitimately omit definition of STDC_VERSION, in addition to c++ mode? Might be, obj-C?

At least in one instance below, you left the check alone.

474

This is actually a good documentation for __offsetof. I request to keep it at least as a comment.

[imp]

tweaks from kib's review

[imp]

OK. I think I've addressed everything. If I've overlooked something, or you don't like how I've addressed it, please let me know.

sys/sys/cdefs.h

84–88

Thanks, will reword.

298

OK. I'm going to delete the comment and uncomment the code

339

Hmmm, yea, I'm going to delete the clang and oldcc check, assume they are always true and simplify from there.

474

ok

[imp]

This has landed, though in too many commits to document here.