Re: C++ constexpr woes while updating firefox [vs. FreeBSD C++ std::pair never being a Trivial Type?]

On 5/11/26 12:16, Mark Millard wrote:
> On 5/11/26 11:36, Christoph Moench-Tegeder wrote:
>> Hi,
>>
>> I'm stumbling on a problem (propably) related to C++ constexpr while
>> updating firefox (current beta).
>>
>> The frame of reference here is FreeBSD 14.4-STABLE amd64, with llvm19
>> from ports (default) (but switching to llvm21 makes no difference).
>>
>> The relevant build failure seems start with this:
>>
>> In file included from /wrkdirs/usr/ports/www/firefox/work/firefox-151.0/js/src/builtin/intl/SharedIntlData.h:21:
>> /wrkdirs/usr/ports/www/firefox/work/firefox-151.0/js/src/util/LanguageId.h:234:66: error: constexpr function's return type 'mozilla::Maybe<std::pair<LanguageId, size_t>>' (aka 'Maybe<pair<js::LanguageId, unsigned long>>') is not a literal type
>>   234 |   static constexpr mozilla::Maybe<std::pair<LanguageId, size_t>> from(
>>       |                                                                  ^
>> /wrkdirs/usr/ports/www/firefox/work/.build/dist/include/mozilla/Maybe.h:367:7: note: 'Maybe<std::pair<js::LanguageId, unsigned long>>' is not literal because it has base class 'detail::MaybeStorage<std::pair<js::LanguageId, unsigned long>>' of non-literal type
>>   367 |     : private detail::MaybeStorage<T>,
>>       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I have vague  memories of FreeBSD having an ABI issue for backwards
> compatibility that affects/limits some types of usage of pair and such
> in modern C++: what is allowed vs. how the language standards progressed
> --related to not updating the ABI.
> 
> But it could take notable time to track down whatever the actual issue
> was vs. my vague association. It all could be irrelevant here.

Looks like it may not apply to your context, although there is a FreeBSD
oddity here still relative to the modern C++ standards and the type
std::pair .

The FreeBSD OS ABI for the c++ pair type still does not support trivial
copy constructors. See:

/usr/src/contrib/llvm-project/libcxx/include/__configuration/abi.h

which, in main, still has (warning: extra line wrapping):

. . .
#elif _LIBCPP_ABI_VERSION == 1
#  if !(defined(_LIBCPP_OBJECT_FORMAT_COFF) ||
defined(_LIBCPP_OBJECT_FORMAT_XCOFF))
. . .
#  endif
// Feature macros for disabling pre ABI v1 features. All of these options
// are deprecated.
#  if defined(__FreeBSD__)
#    define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR
#  endif
#endif
. . .

There was a time when upstream had:

#  if defined(__FreeBSD__) && __FreeBSD__ < 14

but FreeBSD never used that and upstream was later reverted to the
historical status relative to the modern C++ standard versions.


As for why it might not apply to your context: the copy constructor
status did not contribute to the Literal Type classification. (But see
below.)

These days the copy constructor status does contribute to the Trivial
Type classification: FreeBSD's C++ pair is not a Trivial Type, despite
what modern enough language standards specify for pair.

A possibility is that the messaging should have referenced Trivial Type
instead.

But, C++17 deprecated std::is_literal_type and C++20 removed it
completely as not all that useful for generic code use.
std::is_literal_type indicating yes was necessary but not sufficient to
determine if the type could be used in a constant expression. More
detailed type traits were added and C++20 added the Structural Type
concept as well. (The modern standards still references an idea of a
Literal Type.)

> 
>>
>> The code in question is here (the build systems does some shuffling):
>> - Maybe.h: https://github.com/mozilla-firefox/firefox/blob/beta/mfbt/Maybe.h
>>   Especially detail::MaybeStorage is defined starting here:
>>   https://github.com/mozilla-firefox/firefox/blob/beta/mfbt/Maybe.h#L238
>> - LanguageId.h: https://github.com/mozilla-firefox/firefox/blob/beta/js/src/util/LanguageId.h
>>
>> As far as I can see, the whole class setup is independent of OS and
>> compiler - that is, the other (major) platforms have no problem compiling
>> this.
>> I feel like I'm missing some major thing here - I've exhausted my sparse
>> C++ knowledge and I'm now officially out of my depths.
>>
>> Has anyone a hint how to proceed here?
>> I can provide full logs, but the output is about 15MB and rather
>> uneventful (I believe). I'll ask the Mozilla people in parallel; but this
>> seems to be rather specific...
>>
>> Regards,
>> Christoph
>>
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com