This is an archive of the discontinued LLVM Phabricator instance.

libcxxabi [PR58117][NFC]: Open code lower bound
ClosedPublic

Authored by urnathan on Oct 12 2022, 11:05 AM.

Details

Reviewers
arichardson
Group Reviewers
Restricted Project
Commits
rGc7ca21436d62: libcxxabi [PR58117][NFC]: Open code lower bound
Summary

This open codes the use of lower-bound when looking for an operator
encoding. Using std::lower_bound can result in symbol references to
the C++ library and that breaks the ABI demangler, which mandates no
such dependency.

Diff Detail

Event Timeline

urnathan created this revision.Oct 12 2022, 11:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 12 2022, 11:05 AM
urnathan requested review of this revision.Oct 12 2022, 11:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 12 2022, 11:05 AM

Commit message should include Fixes: https://github.com/llvm/llvm-project/issues/58117, otherwise LGTM.

I think it would actually be better to define #define _LIBCPP_ENABLE_ASSERTIONS 0 at the top of the file. That way, we (1) retain the ability to use std algorithms, and we don't risk someone else breaking this in the future. WDYT?

I think it would actually be better to define #define _LIBCPP_ENABLE_ASSERTIONS 0 at the top of the file. That way, we (1) retain the ability to use std algorithms, and we don't risk someone else breaking this in the future. WDYT?

I thought you disliked that solution -- have you changed your mind? (the define would work for me too)

I think it would actually be better to define #define _LIBCPP_ENABLE_ASSERTIONS 0 at the top of the file. That way, we (1) retain the ability to use std algorithms, and we don't risk someone else breaking this in the future. WDYT?

I thought you disliked that solution -- have you changed your mind? (the define would work for me too)

I've realized the #define solution is unfriendly to header-units/clang-modules, and introduces an ODR problem -- the definitions for templates etc will not be the same.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 20 2022, 6:11 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 6:11 AM
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald Transcript

I thought you disliked that solution -- have you changed your mind? (the define would work for me too)

Did I mention that in another review? I don't remember. Either way, this LGTM too, but I think the code may break in the future in a similar way if someone unsuspecting adds a use of a stdlib algorithm, or even worse, if we add new assertions to existing stdlib algorithms.