[Merged by Bors] - Upgraded to ICU 1.2

[Razican]

This PR upgrades ICU to 1.2.

Unfortunately we still have some breaking changes, so this is being handled in unicode-org/icu4x#3332

[jedel1043]

Imported both deps directly. This is now just blocked on unicode-org/icu4x#3335

[jedel1043]

Just realized we can completely bypass the buffer and any constructors by using the unstable ones.
Just for the note, unstable does sound ominous, but I think we're in the clear, because BoaProvider unconditionally implements DataProvider<M> for all M: KeyedDataMarker, which means that any added or removed P: DataProvider<M> bounds on the constructors should never break our compilation... I think.

@sffc Can you either confirm or deny my assumptions? I can rollback to our old method if needed, just want to be sure since doing it this way simplifies our logic a lot.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	94,591	94,591	0
Passed	71,630	71,630	0
Ignored	17,634	17,634	0
Failed	5,327	5,327	0
Panics	0	0	0
Conformance	75.73%	75.73%	0.00%

[codecov]

Codecov Report

Merging #2826 (f34e028) into main (4b72c06) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2826   +/-   ##
=======================================
  Coverage   51.38%   51.38%           
=======================================
  Files         417      417           
  Lines       41330    41328    -2     
=======================================
  Hits        21238    21238           
+ Misses      20092    20090    -2     

Impacted Files	Coverage Δ
boa_engine/src/context/icu.rs	39.58% <ø> (ø)

... and 3 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[sffc]

@sffc Can you either confirm or deny my assumptions? I can rollback to our old method if needed, just want to be sure since doing it this way simplifies our logic a lot.

Yes, you have a blanket impl that leverages as_deserializing and as_downcasting, so you can use unstable constructors. The only catch is that the unstable constructors can't read from deprecated data keys, which we did for the first time in this release when we split the LocaleExpander key in three. So unless you regenerate your data, LocaleExpander will fail to construct. Using the non-unstable constructors allows you to use the old data key (they will map it for you internally).

impl<M> DataProvider<M> for BoaProvider<'_>
where
    M: KeyedDataMarker + 'static,
    for<'de> YokeTraitHack<<M::Yokeable as Yokeable<'de>>::Output>: Deserialize<'de>,
    for<'a> YokeTraitHack<<M::Yokeable as Yokeable<'a>>::Output>: Clone,
    M::Yokeable: ZeroFrom<'static, M::Yokeable> + MaybeSendSync,
{
    fn load(&self, req: DataRequest<'_>) -> Result<DataResponse<M>, DataError> {
        match self {
            BoaProvider::Buffer(provider) => provider.as_deserializing().load(req),
            BoaProvider::Any(provider) => provider.as_downcasting().load(req),
        }
    }
}

[jedel1043]

The only catch is that the unstable constructors can't read from deprecated data keys, which we did for the first time in this release when we split the LocaleExpander key in three.

Oh, that's pretty important, since I'd like to give our users the option to upgrade their dataset when they want, instead of forcing them to regenerate when we bump icu to the latest version. I'll rollback that change.

This is still blocked on that PR then.

[Razican]

I rebased this to the latest main branch and squashed commits. I also tried to "patch" cargo using the branch of the PR in ICU to see if it worked, but it seems that something is not quite right, probably some double-dependency. Let's wait for the 1.2.1 release, and then we can make this proper :)

[sffc]

icu_locid_transform version 1.2.1 is released. This should unblock your upgrade

[Razican]

Suggested change

	codegen-units = 1
	codegen-units = 1

[Razican]

This looks good :) I would run a cargo update before merging (and should we re-generate the data file?), and add that end-of-file new line in Cargo.toml, but for the rest, I think we can merge it!

Thank you @sffc for your fast response!

[jedel1043]

Ran datagen but git didn't detect any diff. Everything good!

[HalidOdat]

Looks good to me! :)

[HalidOdat]

bors r+

[bors]

👎 Rejected by label

[jedel1043]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• Build and Test (macos-latest)
• Build and Test (windows-latest)
• Coverage
• Misc