Proposal: base/ macros that supersede ABSL_ATTRIBUTE_*

[Peter Kasting]

[Follow-on from proposing this in Dana's thread about [[clang::attributes]].]

I propose that, for all ABSL_ATTRIBUTE_* we care about (current or future), we either:

* Use a standardized C++ attribute directly (where possible)

* Define a non-prefixed macro in base/compiler_specific.h; have the implementation prefer C++-standard [[clang::xxx]] or similar syntax over __attribute__((xxx)) (where possible)

...and then ban direct use of the ABSL_ versions.

This would affect very few files today (<20). We currently use the following ABSL_ATTTRIBUTEs:

_LIFETIME_BOUND (most of them)

_WEAK

_NO_TAIL_CALL

_PACKED

_RETURNS_NONNULL

Dana has also expressed interest in future use of _PURE_FUNCTION and _CONST_FUNCTION.

Motivation: The ABSL_ macros are much longer and have a harder-to-remember #include. They also tend to be based on __attribute__(()) even when [[]] would be available, leading to usage that has to be tweaked if later migrated to C++ attribute syntax.

I propose the following names, start your bikesheds:

LIFETIME_BOUND

WEAK_SYMBOL

DISABLE_TAIL_CALLS

PACKED_OBJ

RETURNS_NONNULL

PURE_FUNCTION

CONST_FUNCTION

PK

[danakj]

This SGTM

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFCM0S7MNy3GcNz8Hi0doAFhjPHBDUGa4B2qSu-%2BP%2BJP1g%40mail.gmail.com.

[Peter Boström]

Bikeshed color, do we want to prefix these with BASE_LIFETIME_BOUND to avoid future collisions with 3p dependencies?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaQkTeyfnr%3Ddb7dVvVU%3D891Gf1%2BfGA2iD%3D0aa0GrCsou8A%40mail.gmail.com.

[Peter Kasting]

On Tue, Mar 12, 2024 at 9:53 AM Peter Boström <pb...@chromium.org> wrote:

Bikeshed color, do we want to prefix these with BASE_LIFETIME_BOUND to avoid future collisions with 3p dependencies?

Weak no. We haven't done so for any of our macros in the past and we don't intend to be consumed by third_party code; other code which _does_ so intend should guard its own macros.

PK

[Peter Boström]

Yeah, but we do consume 3p code. LOG() is one such collision where we're lucky that 3p library headers aren't transitively pulling in LOG() for us from absl (also unprefixed). Imo these are timebombs waiting to go off. Attributes are much likelier to be included from header files => likelier transitive-include risk.

[Peter Kasting]

On Tue, Mar 12, 2024 at 9:57 AM Peter Boström <pb...@chromium.org> wrote:

Yeah, but we do consume 3p code. LOG() is one such collision where we're lucky that 3p library headers aren't transitively pulling in LOG() for us from absl (also unprefixed). Imo these are timebombs waiting to go off. Attributes are much likelier to be included from header files => likelier transitive-include risk.

Yes, and I'm saying, if _other_ libraries intend to be consumed (as absl does), _they_ should prefix. LOG() in absl should be ABSL_LOG(). I know, probably not going to happen. :P

PK

[David Benjamin]

This is somewhat a digression, but Abseil has both LOG and ABSL_LOG, and code that needs to coexist with libraries should be using the latter. See go/totw/216 (internal).

David

 

[Peter Boström]

Alright, if we don't think that 3p collisions are likely I don't mind skipping BASE_.

[Danil Chapovalov]

Side note about absl LOG (and CHECK) macros:

absl expose both LOG and ABSL_LOG macros with exactly same functionality,

But build targets that expose LOG family of macros are intentionally unavailable for third party libraries that build with chromium.

Because of that few libraries had to migrate from LOG to ABSL_LOG before being imported into chromium.

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBmS9%2BO8m3VhhLvaHydUf132SSmpNZ0qUmh52BnAFS-Fg%40mail.gmail.com.

[Peter Kasting]

On Monday, March 11, 2024 at 6:38:03 PM UTC-7 pkas...@google.com wrote:

I propose that, for all ABSL_ATTRIBUTE_* we care about (current or future), we either:

* Use a standardized C++ attribute directly (where possible)

* Define a non-prefixed macro in base/compiler_specific.h; have the implementation prefer C++-standard [[clang::xxx]] or similar syntax over __attribute__((xxx)) (where possible)

...and then ban direct use of the ABSL_ versions.

Belatedly, it's been a while and I've seen agreement and no disagreement. I consider this approved. Someone is welcome to implement the above; otherwise I will hopefully get to it eventually.

PK