Summary

The goal for this issue is to bring Hermes to parity with its predecessor Intl implementations, ensuring alignment with the ECMA-402 specification.

Motivation

Hermes currently lacks support for Intl APIs that were available in its predecessor, Chakra/V8. This gap causes issues for customers requiring i18n integration for features like date, time and string formatting based on client device locale settings. Related discussions on this topic can be referenced in items facebook/hermes#630 and (MSFT INTERNAL) Deliverable 36976172.

Current Status

There's a PR of a basic datetimeformat object with documented limitations. Due to the amount of time and effort it takes to add these objects, we will do them on an as-needed basis.

Hi, I have a request to fix the BinSkim errors with hermes. Looks like you'll need to change build flags to disable MD5 hashing and re-enable warnings 4146;4244;4267. When I run the task in our build pipeline, here's what binskim is showing us:

`hermes.dll: error BA2004: 'hermes.dll' is a native binary that directly compiles and links one or more object files which were hashed using an insecure checksum algorithm (MD5). MD5 is subject to collision attacks and its use can compromise supply chain integrity. Pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing.

hermes.dll: error BA2007: 'hermes.dll' disables compiler warning(s) which are required by policy. A compiler warning is typically required if it has a high likelihood of flagging memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, enable the indicated warning(s)`

See __vcpkg.targets:

      <AdditionalLibraryDirectories Condition="'$(__VcpkgNormalizedConfiguration)' == 'Release'">%(AdditionalLibraryDirectories);$(__VcpkgRoot)lib;$(__VcpkgRoot)lib\manual-link</AdditionalLibraryDirectories>
      <AdditionalLibraryDirectories Condition="'$(__VcpkgNormalizedConfiguration)' == 'Debug'">%(AdditionalLibraryDirectories);$(__VcpkgRoot)debug\lib;$(__VcpkgRoot)debug\lib\manual-link</AdditionalLibraryDirectories>

Library paths are suffixed with non-existing directory manual-link.
This prevents LIB dependencies from being resolved by consuming projects.

Suggested solution: Remove the \manual-link suffix from the .targets file.
Additional suggestion: Move MSBuild properties and item definitions into a .props file instead.

Problem

We need to add tests to this repo

Solution

Update .ado/jobs.yml to have tests run and remove the step with [Test] TODO

When building a uwp app against hermes-windows I am finding that a bunch of functionality that is defined in jsi.cpp is missing from the dll. Namely, destructors for a lot of the types are missing, and all of the implementation for HostObject too.

Problem Description

We have recently switched to Hermes to leverage Direct Debugging via VSCode. Unfortunately, we have been noticing that large datasets have been taking around 20 times longer in Hermes to process promises verses Chakra. Specifically, datasets that take 1.2 seconds with Chakra verses 25 seconds with Hermes.

I have been able to reproduce this with a simple React Native app available at hermes-promise-test, which uses version 0.68.0. Our metadata application often processes fields based on various rule sets. I have replicated this in the aforementioned repository by formatting the data set field values to uppercase or lowercase. The results are as follows:

1. Flat (one promise per field) of 1,000 objects: 73.29 ms vs 4.71 ms or 15.5 times longer for Hermes.
2. Flat of 10,000 objects: 748 ms vs 23 ms or 32 times longer for Hermes.
3. Nested (each object has a Promise.all() for every field (6)) of 1,000 objects: 379 ms vs 9 ms or 41 times longer for Hermes.
4. Nested of 10,000 objects: 23626 ms vs 145 ms or 163 times longer for Hermes.

Steps To Reproduce

1. Checkout hermes-promise-test
2. Observe Hermes and Chakra differences by toggling between the two engines by pressing Ctrl + Shift + D and selecting "<Enable/Disable> Remote JS Debugging".
3. Choose Mock Data with Flat Promises or Mock Data with Nested Promises
4. Click either Get 1k Object Cells or Get 10k Object Cells to populate data.
5. Click the Format button to process the data set. Note that times will appear in the console log.

Expected Results

Hermes to perform similar or better than Chakra.

CLI version

7.0.3

Environment

System:
    OS: Windows 10 10.0.19042
    CPU: (16) x64 Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz
    Memory: 16.96 GB / 31.75 GB
  Binaries:
    Node: 16.14.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.15 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.3.1 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 28, 29, 30
      Build Tools: 28.0.3, 29.0.2, 30.0.3, 31.0.0
      System Images: android-30 | Google APIs Intel x86 Atom
      Android NDK: Not Found
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
      Versions: 10.0.16299.0, 10.0.18362.0, 10.0.19041.0
  IDEs:
    Android Studio: Version  4.2.0.0 AI-202.7660.26.42.7351085
    Visual Studio: 16.11.32228.343 (Visual Studio Enterprise 2019)
  Languages:
    Java: 11.0.10 - C:\Program Files\Microsoft\jdk-11.0.10.9-hotspot\bin\javac.EXE
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.2 => 17.0.2
    react-native: 0.68.0 => 0.68.0
    react-native-windows: 0.68.0 => 0.68.0
  npmGlobalPackages:
    *react-native*: Not Found

Target Platform Version

10.0.19041

Target Device(s)

Desktop

Visual Studio Version

Visual Studio 2019

Build Configuration

Debug

Snack, code example, screenshot, or link to a repository

https://github.com/AlexLablaiksSAP/hermes-promise-test

Bug Description

NOTE: Originally from: microsoft/react-native-windows#9681. The following descriptions are assuming use of RNW.

When building/running in debug mode, if a JavaScript function calls into a turbo module (that uses JSI) and passes a string that contains embedded NULs (e.g. "foo\0bar"), then the function in the native module - when it calls jsi::String::utf8 to convert the string into a std::string - will only get the contents of the string up to the first embedded NUL character (e.g. "foo" in the earlier example). It seems that this line is to blame. It seems to make use of the IHermesString interface which only contains a c_str function. Therefore, the std::string constructor will only initialize the string up to the first NUL character.

The fix should be relatively simple: the IHermesString interface needs to also provide a length/size function, and then the hermes_dbg.h header needs to make use of this function.

• I have run gradle clean and confirmed this bug does not occur with JSC

Hermes version: 0.10.0-ms.1
React Native version (if any): 0.67
OS version (if any): Windows Insider
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): amd64

Steps To Reproduce

The easiest way to reproduce is to create a RNW application, set it to use Hermes, add a turbo module, introduce a function that expects a string, call it from JavaScript with a string that contains an embedded NUL, and then expect the contents of the string (e.g. in the debugger) after calling jsi::String::utf8.

The Expected Behavior

Embedded NUL characters should be preserved in Debug like they are in Release

Problem

Further development of Intl objects, add Intl::Collator following ECMA standards. https://402.ecma-international.org/9.0/#numberformat-objects

We probably need a windbg extension for this.

Summary

Tracking the state of DateTimeFormat on Windows, via #127 we added basic support for a default DateTimeFormat Object but still need to fill out implementation for DateTimeFormat::formatToParts (https://402.ecma-international.org/9.0/#sec-Intl.DateTimeFormat.prototype.formatToParts)

Motivation

See #87

ECMA402 defines an order in which the keys are returned in DateTimeFormat::resolvedOptions. Currently Windows and Android do not pass these tests because we don't specify an order.

Otherwise people have to rebuild from source every time they want to debug

Bug Description

PkgESSecComp@10 is required for many internal pipelines for compliance to ensure the most appropriate flags are set when compiling binaries.

Currently, it runs the pipeline task on hermes.dll (with hermes.pdb downloaded from symbol server), PkgESSecComp flags several issues:

Example: Pipeline Run

CfgChk fails to analyze the binary entirely due to BB0042: There is no fixup debug information in the image 'D:\a\_work\1\b\Native\hermes.dll'. Please link with /DEBUGTYPE:CV,FIXUP.

CheckCFlags2 runs but file a bug for CCF0904 indicating that the compiler arguments are stripped from the PDB so it cannot actually analyze them without building objects with /Z7 and /debug:full. (It also raised CCF1010 but C++ export are clearly expected with the JSI so this would be baselined.)

I have been told that addressing the issue with symbol information is also a requirement for SBOM tooling to process the binaries so multiple compliance tools require these fixes.

The Expected Behavior

Given symbols, hermes.dll should have the right flags set at compilation time such that it is processable by analysis tooling such as CfgChk and CheckCFlags2 can process the binary. Ideally it would also pass CfgChk and CheckCFlags2 too for security reasons, but I expect it is likely that would not be possible with Hermes for reasons like performance or code size so some issues would need to baselined by CCF1010.

(Regarding symbols, given they are not included in the NuGet package, any pipelines consuming hermes.dll have the additional step to implement using symchk (or equivalent) to download them so it would also be ideal if symbols were included in the main or a separate nuget package too.)

Port of microsoft/react-native-windows#9772.

We don't currently keep good track of code that went into a certain Hermes NuGet release, e.g. there is a 0.9.0-ms branch, but that doesn't exactly match the code in the 0.9.0-ms.4 package (we get mismatched source warnings in the debugger).
This is because the branch seems to track only the latest for a given version.
It's important we address this for compliance / security reasons as well as debuggability.

The Hermes symbols seem to only available in symweb; they should be available in the public Microsoft symbol server.

Problem

Hermes crash dumps currently do not link to the repo's source code. This inhibits remote debugging experiences via processes like Watson.

Solution

Following the guidance at https://github.com/dotnet/designs/blob/main/accepted/2020/diagnostics/source-link.md#source-link-json-schema, we must create a sourcelink file and pass the /sourcelink:<file> compiler flag as described in https://docs.microsoft.com/en-us/cpp/build/reference/sourcelink?view=msvc-170 to our build script and/or cmake.

Additional Context

Example in msbuild syntax:

Write out the source file for this project to point at raw.githubusercontent.com
<WriteLinesToFile File="$(SourceLink)" Overwrite="true" Lines='{"documents": { "$(SourceLinkRoot)\\*" : "$(RemoteUri.Replace(".git", "").Replace("github.com", "raw.githubusercontent.com"))/$(LatestCommit)/*" }}' />

Files in the doc folder were forked from facebook/hermes. As such, they are Android-specific and talks about how things integrate with React Native. We should update these files to be about Windows and integration with React Native Windows.

Problem

Currently the Windows implementation of DateTimeFormat::supportedLocalesOf does not support bestFit matching. Android supports this feature while apple does not (yet).

ICU uses localematcher in C++ but does not have an equivalent in C. We should figure out a way around this to add support for bestFit. This will affect supportedLocalesOf NumberFormat and Collator

https://402.ecma-international.org/9.0/#sec-bestfitmatcher

Bug Description

Displaying old dates throws an unhandled exception.
I remember this being in PlatformUnicodeUWP.cpp but I don't have a crash dump handy.

Hermes version: ReactNative.Hermes.Windows.0.1.6
React Native version (if any): 0.60
Android version (if any): n/a
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): x86_64

Steps To Reproduce

new Date("1968-10-06T03:59:59.0000000").toLocaleDateString()

The Expected Behavior

No Crash :)

I was playing with the Hermes DLL in a uwp app and I noticed that we set /delayload for it, but when I try to link against the Hermes dll from nuget I get an unresolved symbol for __delayloadHelper2@8
Any idea what might be going on? Or how RNW manages to avoid hitting this problem?

I’m using the nuget package ReactNative.Hermes 0.6.3 – 0245db0

0.6.3

Problem

Further development of Intl objects, add Intl::Collator following ECMA standards. https://402.ecma-international.org/9.0/#collator-objects

Additional Context

There's a start of this work in forked repository, this may be a good starting point

Once we are done with Hermes for UWP we should unfork it and upstream the changes so that we can get the latest changes incl. security fixes. This will be important to ensure supportability of RNW/Hermes in enterprise environments.

I think Static Hermes is very awesome, and could be a killer function for Flutter.

But for now, it only supports iOS and Android. It would be better for static Hermes to support Windows, Linux, and MacOS.

Bug Description

The Debug build of our React Native Windows project is failing to load a JS bundle file when loading directly from disk (instead of using metro hot-loading). The exception only occurs when using an optimized release version of hermes.dll from our Debug application. Specifically, we are using the checkediterdebugger version of the Release build for hermes.dll included in the ReactNative.Hermes.Windows.0.9.0-ms.4 NuGet package.

Everything works as expected when using a Release build of the application with the Release build of hermes.dll.

The Debug build will also load the bundle successfully while a Visual Studio debugger is attached by simply hitting 'continue'. It looks like this exception is not caught by any try-catch blocks, but the program is able to continue along as if nothing happened if we simply hit 'continue' from the debugger. In this case, everything seems to work as expected If a debugger is not attached then the program crashes before the bundle loads.

Please note that our scenario uses XAML Islands to host the UWP XAML control inside a DesktopWindowXamlSource object so that we can run React Native from an unpackaged Win32 application.

The exception:
Unhandled exception at 0x00007FFEF348BE19 (ntdll.dll) in App.exe:
0xC0000374: A heap has been corrupted (parameters: 0x00007FFEF34F6780).

The call-stack:

     ntdll.dll!00007ffef348bda2()    Unknown
     ntdll.dll!00007ffef3494c02()    Unknown
     ntdll.dll!00007ffef3494eea()    Unknown
     ntdll.dll!00007ffef349f3d5()    Unknown
     ntdll.dll!00007ffef342e012()    Unknown
     ntdll.dll!00007ffef33a7511()    Unknown
     ucrtbase.dll!00007ffef110218b()    Unknown
     [Inline Frame] hermes.dll!std::_Deallocate(void * _Ptr, unsigned __int64 _Bytes) Line 264    C++
     [Inline Frame] hermes.dll!std::allocator<facebook::jsi::PropNameID>::deallocate(facebook::jsi::PropNameID * const) Line 835    C++
     [Inline Frame] hermes.dll!std::vector<facebook::jsi::PropNameID,std::allocator<facebook::jsi::PropNameID>>::_Tidy() Line 1765    C++
     hermes.dll!std::vector<facebook::jsi::PropNameID,std::allocator<facebook::jsi::PropNameID>>::~vector<facebook::jsi::PropNameID,std::allocator<facebook::jsi::PropNameID>>() Line 712    C++
>    hermes.dll!facebook::hermes::HermesRuntimeImpl::JsiProxy::getHostPropertyNames() Line 955    C++
     [Inline Frame] hermes.dll!hermes::vm::HostObject::getHostPropertyNames() Line 120    C++
     hermes.dll!hermes::vm::JSObject::getOwnPropertyKeys(hermes::vm::Handle<hermes::vm::JSObject> selfHandle, hermes::vm::Runtime * runtime, hermes::vm::OwnKeysFlags okFlags) Line 443    C++
     hermes.dll!hermes::vm::getOwnPropertyKeysAsStrings(hermes::vm::Handle<hermes::vm::JSObject> selfHandle, hermes::vm::Runtime * runtime, hermes::vm::OwnKeysFlags okFlags) Line 447    C++
     hermes.dll!hermes::vm::objectGetOwnPropertyNames(void * __formal, hermes::vm::Runtime * runtime, hermes::vm::NativeArgs args) Line 484    C++
     [Inline Frame] hermes.dll!hermes::vm::NativeFunction::_nativeCall(hermes::vm::NativeFunction *) Line 546    C++
     hermes.dll!hermes::vm::Interpreter::handleCallSlowPath(hermes::vm::Runtime * runtime, hermes::vm::PinnedHermesValue * callTarget) Line 285    C++
     hermes.dll!hermes::vm::Interpreter::interpretFunction<0,0>(hermes::vm::Runtime * runtime, hermes::vm::InterpreterState & state) Line 1633    C++
     [Inline Frame] hermes.dll!hermes::vm::Runtime::interpretFunctionImpl(hermes::vm::CodeBlock *) Line 818    C++
     hermes.dll!hermes::vm::Runtime::interpretFunction(hermes::vm::CodeBlock * newCodeBlock) Line 832    C++
     hermes.dll!hermes::vm::JSFunction::_callImpl(hermes::vm::Handle<hermes::vm::Callable> selfHandle, hermes::vm::Runtime * runtime) Line 1284    C++
     [Inline Frame] hermes.dll!hermes::vm::Callable::call(hermes::vm::Handle<hermes::vm::Callable>) Line 275    C++
     hermes.dll!hermes::vm::Callable::executeCall0(hermes::vm::Handle<hermes::vm::Callable> selfHandle, hermes::vm::Runtime * runtime, hermes::vm::Handle<hermes::vm::HermesValue> thisArgHandle, bool construct) Line 248    C++
     hermes.dll!hermes::vm::JSObject::getNamedWithReceiver_RJS(hermes::vm::Handle<hermes::vm::JSObject> selfHandle, hermes::vm::Runtime * runtime, hermes::vm::SymbolID name, hermes::vm::Handle<hermes::vm::HermesValue> receiver, hermes::vm::PropOpFlags opFlags, hermes::vm::PropertyCacheEntry * cacheEntry) Line 1096    C++
     hermes.dll!hermes::vm::Interpreter::interpretFunction<0,0>(hermes::vm::Runtime * runtime, hermes::vm::InterpreterState & state) Line 2387    C++
     [Inline Frame] hermes.dll!hermes::vm::Runtime::interpretFunctionImpl(hermes::vm::CodeBlock *) Line 818    C++
     hermes.dll!hermes::vm::Runtime::interpretFunction(hermes::vm::CodeBlock * newCodeBlock) Line 832    C++
     hermes.dll!hermes::vm::JSFunction::_callImpl(hermes::vm::Handle<hermes::vm::Callable> selfHandle, hermes::vm::Runtime * runtime) Line 1284    C++
     [Inline Frame] hermes.dll!hermes::vm::Callable::call(hermes::vm::Handle<hermes::vm::Callable>) Line 275    C++
     hermes.dll!hermes::vm::Callable::executeCall0(hermes::vm::Handle<hermes::vm::Callable> selfHandle, hermes::vm::Runtime * runtime, hermes::vm::Handle<hermes::vm::HermesValue> thisArgHandle, bool construct) Line 248    C++
     hermes.dll!hermes::vm::JSObject::getNamedWithReceiver_RJS(hermes::vm::Handle<hermes::vm::JSObject> selfHandle, hermes::vm::Runtime * runtime, hermes::vm::SymbolID name, hermes::vm::Handle<hermes::vm::HermesValue> receiver, hermes::vm::PropOpFlags opFlags, hermes::vm::PropertyCacheEntry * cacheEntry) Line 1096    C++
     hermes.dll!hermes::vm::Interpreter::interpretFunction<0,0>(hermes::vm::Runtime * runtime, hermes::vm::InterpreterState & state) Line 2387    C++
     [Inline Frame] hermes.dll!hermes::vm::Runtime::interpretFunctionImpl(hermes::vm::CodeBlock *) Line 818    C++
     hermes.dll!hermes::vm::Runtime::interpretFunction(hermes::vm::CodeBlock * newCodeBlock) Line 832    C++
     hermes.dll!hermes::vm::Runtime::runBytecode(std::shared_ptr<hermes::hbc::BCProviderBase> && bytecode, hermes::vm::RuntimeModuleFlags flags, llvh::StringRef sourceURL, hermes::vm::Handle<hermes::vm::Environment> environment, hermes::vm::Handle<hermes::vm::HermesValue> thisArg) Line 1017    C++
     [Inline Frame] hermes.dll!hermes::vm::Runtime::runBytecode(std::shared_ptr<hermes::hbc::BCProviderBase> &&) Line 277    C++
     hermes.dll!facebook::hermes::HermesRuntimeImpl::evaluatePreparedJavaScript::__l2::<lambda>() Line 1509    C++
     [Inline Frame] hermes.dll!?A0xa7b9cf34::maybeRethrow(const facebook::hermes::HermesRuntimeImpl::evaluatePreparedJavaScript::__l2::facebook::jsi::Value <lambda>(void) &) Line 109    C++
     [Inline Frame] hermes.dll!facebook::hermes::HermesRuntimeImpl::evaluatePreparedJavaScript(const std::shared_ptr<facebook::jsi::PreparedJavaScript const> &) Line 1499    C++
     hermes.dll!facebook::hermes::HermesRuntime::evaluateJavaScriptWithSourceMap(const std::shared_ptr<facebook::jsi::Buffer const> & buffer, const std::shared_ptr<facebook::jsi::Buffer const> & sourceMapBuf, const std::string & sourceURL) Line 1372    C++
     hermes.dll!facebook::hermes::HermesRuntimeImpl::evaluateJavaScript(const std::shared_ptr<facebook::jsi::Buffer const> & buffer, const std::string & sourceURL) Line 1522    C++
     Microsoft.ReactNative.dll!facebook::jsi::RuntimeDecorator<facebook::hermes::HermesRuntime,facebook::jsi::Runtime>::evaluateJavaScript(const std::shared_ptr<facebook::jsi::Buffer const> & buffer, const std::string & sourceURL) Line 118    C++
     Microsoft.ReactNative.dll!facebook::react::JSIExecutor::loadBundle(std::unique_ptr<facebook::react::JSBigString const ,std::default_delete<facebook::react::JSBigString const>> script, std::string sourceURL) Line 159    C++
     Microsoft.ReactNative.dll!facebook::react::NativeToJsBridge::loadBundleSync(std::unique_ptr<facebook::react::RAMBundleRegistry,std::default_delete<facebook::react::RAMBundleRegistry>> bundleRegistry, std::unique_ptr<facebook::react::JSBigString const ,std::default_delete<facebook::react::JSBigString const>> startupScript, std::string startupScriptSourceURL) Line 163    C++
     Microsoft.ReactNative.dll!facebook::react::Instance::loadBundleSync(std::unique_ptr<facebook::react::RAMBundleRegistry,std::default_delete<facebook::react::RAMBundleRegistry>> bundleRegistry, std::unique_ptr<facebook::react::JSBigString const ,std::default_delete<facebook::react::JSBigString const>> string, std::string sourceURL) Line 89    C++
     Microsoft.ReactNative.dll!facebook::react::Instance::loadScriptFromString(std::unique_ptr<facebook::react::JSBigString const ,std::default_delete<facebook::react::JSBigString const>> string, std::string sourceURL, bool loadSynchronously) Line 107    C++
     Microsoft.ReactNative.dll!facebook::react::InstanceImpl::loadBundleInternal(std::string && jsBundleRelativePath, bool synchronously) Line 592    C++
     Microsoft.ReactNative.dll!facebook::react::InstanceImpl::loadBundleSync(std::string && jsBundleRelativePath) Line 462    C++
     Microsoft.ReactNative.dll!Mso::React::ReactInstanceWin::LoadJSBundles::__l7::<lambda>() Line 564    C++
     [External Code]    
     Microsoft.ReactNative.dll!Mso::React::MessageDispatchQueue::tryFunc(const std::function<void __cdecl(void)> & func) Line 41    C++
     Microsoft.ReactNative.dll!Mso::React::MessageDispatchQueue::runOnQueue::__l2::<lambda>() Line 36    C++
     Microsoft.ReactNative.dll!Mso::Details::FunctionObjectWrapper<void <lambda>(void),void>::Invoke() Line 166    C++
     Microsoft.ReactNative.dll!Mso::QueueService::InvokeTask(Mso::Functor<void __cdecl(void)> && task, std::optional<std::chrono::time_point<std::chrono::steady_clock,std::chrono::duration<__int64,std::ratio<1,1000000000>>>> endTime) Line 208    C++
     Microsoft.ReactNative.dll!Mso::LooperScheduler::RunLoop(const Mso::WeakPtr<Mso::LooperScheduler> & weakSelf) Line 49    C++
     Microsoft.ReactNative.dll!Mso::LooperScheduler::<lambda>() Line 36    C++
     [External Code] 

• [NA] I have run gradle clean and confirmed this bug does not occur with JSC

Hermes version: ReactNative.Hermes.Windows.0.9.0-ms.4
React Native version (if any): 0.66.0
OS version (if any): Windows 11 / Version 21H2 / OS Build 22000.258
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): x64

Steps To Reproduce

Please see Bug Description for details. Code sample can be provided on request [INTERNAL].

The Expected Behavior

Debug builds of unpackaged Win32 React Native applications running via XAML Islands should be able to load bundles using the optimized Release build of hermes.dll.

Bug Description

Hermes currently does not include proper Licensing information which gets flagged by component governance in ADO.

• I have run gradle clean and confirmed this bug does not occur with JSC

Hermes version: 0.11.2

Bug Description

This looks like a bug in the Windows APIs being called by the C Runtime.

https://www.gizchina.com/2020/03/07/a-new-windows-10-bug-microsoft-has-980-years-to-fix-it/
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-s-localtime32-s-localtime64-s?view=vs-2019

_localtime64_s, which uses the __time64_t structure, allows dates to be expressed up through 23:59:59, January 18, 3001, coordinated universal time (UTC), whereas _localtime32_s represents dates through 23:59:59 January 18, 2038, UTC.

Hermes version: ReactNative.Hermes.Windows.0.1.6
React Native version (if any): 0.60
Android version (if any): n/a
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): x86_64

Steps To Reproduce

new Date("3002-10-06T03:59:59.0000000").toLocaleDateString()

The Expected Behavior

No Crash :)

Problem

Further development of Intl objects, add toLocaleLowerCase and toLocaleUpperCase following ECMA standards.
https://402.ecma-international.org/9.0/#sup-string.prototype.tolocaleuppercase

Summary

React Native switched to Hermes as the default JavaScript Engine in .70, RNW should target .73 as our candidate to switch to Hermes. This tracks what currently needs to be accomplished before making the switch. Edit as needed with new issues.

The PDBs in the nuget package are mismatched with the binaries
using 0.6.3 nuget pkg

Hermes / inspector requires Folly APIs not available to UWP, filing this to track on the Hermes side.
Related: microsoft/react-native-windows#6137