Rustc passes -nodefaultlibs to the linker (clang) on mac, which prevents
clang from adding the necessary sanitizer runtimes when building with
C/C++ sanitizer but without rust sanitizer. This normally only causes grief
when building a bin crate, but cargo also builds all artifacts of crates with
multiple crate-types, so when adding libz-rs-sys, which has both rlib and
cdylib type, cargo tries to build the cdylib, which can fail to link for the
same reasons. We thus needs to expand the scope of the previous hack to apply
to all targets, not only building bin crates, and to all rustc compilations,
since CARGO_RUSTCFLAGS only applies to the root crate of the cargo invocation.
Differential Revision: https://phabricator.services.mozilla.com/D219212
Implement the following operations:
- CalendarDateMonth
- CalendarDateDay
- CalendarDateDayOfWeek
- CalendarDateWeekOfYear
- CalendarDateDaysInWeek
- CalendarDateDaysInMonth
- CalendarDateDaysInYear
- CalendarDateMonthsInYear
Calendar arithmetic isn't currently supported in ICU4X through the public
API, so for now we simply default to the ISO calendar operations for:
- CalendarDateAddition
- CalendarDateDifference
---
Calendrical computations are performed through ICU4X instead of ICU4C, as
previously discussed on multiple occasions.
The Temporal spec leaves the concrete semantics of any calendar except the
ISO-8601 calendar as implementation-defined, so we're free to implement things
however we like. For better cross-engine compatibility, certain aspects should
probably clarified, though. For example in the Japanese calendar with its
regnal eras, if the user-supplied `eraYear` exceeds the named era, do we
constrain `eraYear` to the end of the era or do we alternatively switch to the
next era? Bug reports against the Temporal spec repo will be written to clarify
these points.
This patch doesn't perform any caching, so the ICU4X calendar and date types are
created from scratch for all operations. This will likely be too slow (10-100x
slow-downs when compared to using the non-ICU4X based ISO-8601 calendar), so in
a follow-up bug we likely need to investigate how to add some sort of caching.
And just as with `Intl.Segmenter`, we're using the ICU4X C-API instead of the
C++ API, see also <https://github.com/rust-diplomat/diplomat/issues/280>.
Differential Revision: https://phabricator.services.mozilla.com/D211766
Actually remove the check for demangle, no supported target need that
check.
Also make library dependencies explicit instead of relying on "$LIBS".
Differential Revision: https://phabricator.services.mozilla.com/D203637
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
The previous implementation used days since Jan 1 2000 for the last
16-bit segment. This was not unique enough and caused issues with
Antivirus software if two different channels were built on the same day.
The new approach uses hours since the last milestone bump and uses the
VCS to determine how long ago that was relative to the build time. This
means it will always reset when a new cycle begins, but still be unique
since the digits in the first 3 segments have incremented.
We also now use two of the 16-bits to encode the channel (nightly, beta,
ESR, and release). So two channels built within the same hour will still
be unique.
Using only 14-bits to store the 'hours since version bump', we have
about ~682 days from a version bump before we reach the maximum value we
can store. If a build is done after that point, the segment value will
always be the maximum value for that channel.
Differential Revision: https://phabricator.services.mozilla.com/D200989
Actually remove the check for demangle, no supported target need that
check.
Also make library dependencies explicit instead of relying on "$LIBS".
Differential Revision: https://phabricator.services.mozilla.com/D203637
