Enabling Rust support for Temporal

Hi!

I've been working on implementing ECMAScript Temporal upstream in V8. It's being implemented based on the temporal_rs and icu4x libraries, which are in Rust.

As such, it needs Rust support to work (initial V8 CL for adding Rust to DEPS.

When first working on this feature V8-in-Node CI was failing due to the lack of these vendored deps. So V8 now has a v8_enable_temporal_support that is enabled by default¹ but disabled in some builds, including the Node build.

Presumably, NodeJS will eventually want to have support for Temporal. It's probably worth figuring out what is needed to get there even though there's still a fair amount of time for us to be ready to ship.

Opening this issue to start the conversation; I'm happy to help out upstream if needed.

A challenge that may crop up is that Node vendors v8 which means that it will have to vendor third_party/rust and the toolchain: currently V8's third_party/rust is the same as that of Chrome, which includes a lot of extra Rust deps that Chrome has (so far this hasn't been a problem). If Node doesn't wish to pull all of that in, it may need to do something build-system wise to download those deps but not check them in to the tree.

Temporal is still disabled at runtime by default (the implementation is not ready); but it still gets built. ↩

@Manishearth

Thanks @Manishearth

It's very hacky (I edited a few ninja files manually to make it work) but it builds!

$ out/Release/node --harmony-temporal -p Temporal
Object [Temporal] {}

What needs to be done in the gyp file to avoid the manual steps:

Run cargo build --package temporal_capi --features compiled_data (with --release for release builds) from deps/v8/third_party/rust/chromium_crates_io
Add deps/v8/third_party/rust/chromium_crates_io/target/debug/libtemporal_capi.a to the linker's arguments for targets that depend on temporal_capi.

Maybe we should do a new type of gyp target, I'm not sure.

/cc @nodejs/gyp

By the way, once https://issues.chromium.org/issues/427198967 is fixed you may be able to avoid the patching.

fyi @nodejs/platform-smartos, need to make sure Rust/LLVM is supported.

fyi @nodejs/platform-smartos, need to make sure Rust/LLVM is supported.

Thanks for the heads up! We have Tier 2 support in Rust for illumos on amd64. You can use the regular rustup instructions on an illumos system to install them, with the caveat that you should be sure to pipe the shell script to bash rather than sh.

@targos

@targos how's this going along? Are there any ways in which I or upstream can help? We're nearing the point where we'll be unflagging Temporal in V8, and while Node doesn't need to have the same timeline I'm interested in making sure there aren't any barriers in Node's way from upstream, where possible.

@Manishearth

@Manishearth Hi Manish, it seems like nightly builds of Rust is currently needed to build V8? otherwise we get this error:

error: the option `Z` is only accepted on the nightly compiler

Sample flag that triggers it, -Zdep-info-omit-d-target: https://chromium.googlesource.com/chromium/src/+/main/build/config/compiler/BUILD.gn#1116

We use our own Rust binaries on ppc64/s390x (much like gcc/clang) and cannot use binaries provided by the chromium toolchain. Some of our platforms may not have a reliable nightly build of Rust available and can only provide stable builds. Is having a nightly build of Rust a requirement that is going to stay? if so then are there workarounds to this issue?

@miladfarca

@miladfarca None of the code that V8 relies on needs Nightly Rust.

Chromium's ninja integration appears to need it. As I understand it, Node is running its own, modified build, yes? You may be able to figure out your own workaround.

My understanding is that that flag just removes the rule for generating the depinfo (.d) file itself from the depinfo files it generates. You could likely do the same with a script.

Might even be something chrome could upstream as a use_stable_rust option, though

I can also ask the Chrome team if there are ways this can be removed upstream.

@Manishearth

@Manishearth -Z flags are used in more places in the above file, above flag was just an exmaple. Removing them then causes compilation failures, i.e:

error[E0554]: `#![feature]` may not be used on the stable release channel
  --> ../../build/rust/allocator/lib.rs:21:1
   |
21 | #![feature(linkage)]
   | ^^^^^^^^^^^^^^^^^^^^

So not sure how we can continue using stable builds?

@miladfarca

@miladfarca I suspect all of these can be worked around. The linkage feature is being used to make the symbols weak, this can be done with a linker script as well.

Fundamentally, the Temporal in V8 integration is a matter of building temporal_capi as a staticlib and then linking it in. You do not need unstable Rust to do that. You will likely wish to use the vendored Rust crates that V8 vendors (because we will be patching them, etc), so you're somewhat tied to the third_party/rust tree (which unfortunately uses -Zbindeps, but again this subtree doesn't need it, it can be patched out as was done above).

It's mostly a matter of whether you want to do most of the Rust build your own way, or the Chrome way, and if you're doing it the Chrome way then you'll need to work around the unstable features.

You could even do the build the Chrome way except on these few platforms, and on those platforms (and on those platforms only) do it via a well-targeted cargo build.

Basically, what I'm saying is, the actual code being used here does not require nightly. However, the build system infra does (the allocator code you found is a part of that: the v8 code doesn't need a shared allocator, and there are other ways to share allocators that do not require weak linkage). How much you have to work around depends on how much the build system infra you wish to keep.

@Manishearth

@Manishearth Thank you for clarifying, we will look into ways we can patch this. Regarding unflagging Temporal in V8, is it possible to keep it disabled for said platform for the time being: https://source.chromium.org/chromium/chromium/src/+/main:v8/gni/v8.gni;l=64

Yes, I believe that those platforms are not ones Chromium ships on.

That's right, thank you.

Is this why when using --harmony-temporal, Temporal remain undefined?
I see that change since 24.6.0 and wonder if there is a relation with this build chain...

Yes.

@miladfarca

Just checking in the status of this as temporal is unflagged in upstream now. As far as I understand, this is where we are, please correct me if I am wrong:

The CI machines need to have the (at least stable) Rust toolchain installed; The build WG is working through it.
Some tweaks are needed to make V8 build with stable Rust instead of the one stocked in Chromium on all platforms that Node.js support. @miladfarca is working on it as the V8 built on s390x/ppc64le require it - though as far as I can tell, the work is done to make V8 build with GN on those platforms.
Node.js downstream uses GYP instead of GN to build V8, so we'd need to port the configs. @targos figured out how to link it at least manually Enabling Rust support for Temporal #58730 (comment) - what remains to be done is to figure out how to tell GYP to generate the build files to do those manual steps - either a custom target or a custom action (my hunch is the latter is sufficient, that's what we do for some ASM bits from OpenSSL and data surgeries of ICU IIUC).

Am I missing any other blockers?

Work on enabling Rust builds with a stable version of rutsc is almost complete. Majority of the changes are within these two CLs:
https://chromium-review.googlesource.com/c/chromium/src/+/7022369
https://chromium-review.googlesource.com/c/chromium/src/+/7114078

And yes changes need to be ported from GN to GYP. We install rustc using the rust-toolset package form RHEL and then install bindgen with cargo install bindgen-cli. These additional args.gn entries are also needed when compiling V8:

treat_warnings_as_errors = false # temporary until more upstream patches land
v8_enable_temporal_support = true
rust_sysroot_absolute = "/usr"
rust_bindgen_root = "/root/.cargo"
rustc_version = "1.84.1"
clang_version = "19"

build: add flag to compile V8 with Temporal support

I started to port my experiments: #60693

This CL simplifies using older versions of Rust by making use of export RUSTC_BOOTSTRAP=1:
http://crrev.com/c/7153321

It forces usage of unstable features and flags even with a stable version of the rustc. Its behavior is not guaranteed to remain in the future versions of Rust but since we can't use nightly builds this allows us to use older versions of rustc while maintaining fewer patches upstream.

Another reason export RUSTC_BOOTSTRAP=1 is needed is because my custom alloc_error_handlers (which are now removed in the above CL) did not work on Rust version 1.88 and caused link errors. To get around the issue we either need to use a nightly build of rustc or enable nightly features on a stable rustc and just use the handlers provided by Chromium. More details on this topic:
rust-lang/rust#148916

On RHEL I'm currently installing version 1.84 using the rust-toolset-1.84.1 package which has libadler and I've patched Chromium upstream based on it. It switches to libadler2 in Rust 1.86 so if we end up with a rustc >= 1.86 then we need to patch Chromium upstream and potentially introduce a rustc_version_comparable variable.

build: add flag to compile V8 with Temporal support

deps: add temporal_rs 0.1.0

build: add temporal_capi gyp

test: add basic temporal presence check

build: ignore built-in temporal when building with shared lib

build: add flag to compile V8 with Temporal support

deps: add temporal_rs 0.1.0

build: add temporal_capi gyp

test: add basic temporal presence check

build: ignore built-in temporal when building with shared lib

build: add temporal to linux GHA build

doc: add note about rust toolchain version requirement

build: add flag to compile V8 with Temporal support

deps: add temporal_rs 0.1.0

build: add temporal_capi gyp

test: add basic temporal presence check

build: ignore built-in temporal when building with shared lib

build: add flag to compile V8 with Temporal support

deps: add temporal_rs 0.1.0

build: add temporal_capi gyp

test: add basic temporal presence check

build: ignore built-in temporal when building with shared lib

build: enable temporal on GHA macOS build

build: add temporal test on GHA windows

I've removed this from the Build WG agenda as we have nodejs/build#4245 for tracking rust toolchain installation across the Jenkins CI machines.

As far as I am aware we have the configure/gyp scripts in place to opt into build the Temporal crate and waiting for a V8 update (14.4 or newer) to land on main before potentially enabling Temporal by default in the Node.js builds.

@richardlau

@richardlau Of the two blockers in your comment above (Rust toolchain in CI + Node 14.4+ landing in main) is there a rough ETA for when those will be unblocked?

I'm one of the champions of the Temporal proposal and as you can guess have been fielding a lot of "Node support when?" questions since Temporal was shipped in Chrome in January and even more since Temporal reached Stage 4 earlier this month.

@justingrant

@justingrant V8 14.4+ seems to be taken care of by #62526 (Node 26) at least, which seems to be targeting today. In general it claims to enable Temporal by default, so it seems the ETA is today.

We've hit a snag with Temporal under Rosetta 2 on macOS (how we build the universal pkg installer). Unfortunately we've only discovered that today as it was masked by a different failure under Rosetta 2: #63006 (comment)

We've hit a snag with Temporal under Rosetta 2 on macOS (how we build the universal pkg installer). Unfortunately we've only discovered that today as it was masked by a different failure under Rosetta 2: #63006 (comment)

Does that mean that Temporal will work under anything but MacOS with Rosetta, will slip to Node 27, will it just come with a patch/minor release after 26.0, or will 26.0 be delayed?

We've hit a snag with Temporal under Rosetta 2 on macOS (how we build the universal pkg installer). Unfortunately we've only discovered that today as it was masked by a different failure under Rosetta 2: #63006 (comment)

Does that mean that Temporal will work under anything but MacOS with Rosetta, will slip to Node 27, will it just come with a patch/minor release after 26.0, or will 26.0 be delayed?

Unclear/undecided right now, but we cannot release if the pkg build is broken.

Does that mean that Temporal will work under anything but MacOS with Rosetta, will slip to Node 27, will it just come with a patch/minor release after 26.0, or will 26.0 be delayed?

We've pushed node 26 back to next Tuesday while this is worked on.
We have prototyped a fix now.

Does that mean that Temporal will work under anything but MacOS with Rosetta, will slip to Node 27, will it just come with a patch/minor release after 26.0, or will 26.0 be delayed?

We've pushed node 26 back to next Tuesday while this is worked on. We have prototyped a fix now.

26 was released and noted that Temporal is enabled by default in the Blog post--does that mean this is resolved?

Closing as I believe this is resolved. Feel free to reopen if necessary.

It's enabled on all of the tier1/2 platforms shipped from our CI I believe. But at the time of writing it excludes some others such as:

Alpine (Although that's being fixed for x64 in 26.1.0)
Any other unofficial builds e.g. Linux-riscv64
Smartos (tier 2)
IBMi

Added issue #63213 for documentation on prerequisite component installation, and for Windows, additional requirement for checks in vcbuild.bat.

So this is marked as fixed, however I notice that upstream V8 still disabled temporal for Node builds. This disabling was something I'd done with the expectation that whoever works on Node would discover it and reenable it, but that doesn't actually seem to have happened.

https://source.chromium.org/chromium/chromium/src/+/main:v8/gni/v8.gni;l=63-70?q=v8.gni&ss=chromium

What am I missing? Should this be just set to true now? The status quo of Rust-in-V8-in-Node is useful to know since we are working on more Rust components in V8 (https://chromium-review.git.corp.google.com/c/v8/v8/+/8481900, https://chromium-review.git.corp.google.com/c/v8/v8/+/8532166/9)

I guess that because we don't use GN, we haven't noticed it was supposedly disabled for us; we already have it enabled by default (I just opened #66697 to remove the last case it was disabled). I think the only remaining bug is #66184, but it shouldn't affect the build.

Ah, looks like V8 uses node's unofficial gn build for its own CI. Hm.

Navigation Menu

Repository navigation

Enabling Rust support for Temporal #58730

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Enabling Rust support for Temporal #58730

Description

Footnotes

Activity

targos commented on Jun 21, 2025

Manishearth commented on Jun 30, 2025

miladfarca commented on Jul 31, 2025

jclulow commented on Jul 31, 2025

Manishearth commented on Aug 11, 2025

miladfarca commented on Aug 11, 2025

Manishearth commented on Aug 11, 2025

miladfarca commented on Aug 11, 2025

Manishearth commented on Aug 11, 2025

Manishearth commented on Aug 11, 2025

miladfarca commented on Aug 11, 2025

Manishearth commented on Aug 11, 2025

miladfarca commented on Aug 11, 2025

jehon commented on Oct 8, 2025

Manishearth commented on Oct 8, 2025

joyeecheung commented on Nov 8, 2025

miladfarca commented on Nov 9, 2025

targos commented on Nov 12, 2025

miladfarca commented on Nov 14, 2025

miladfarca commented on Nov 16, 2025

richardlau commented on Feb 26, 2026

justingrant commented on Mar 22, 2026

megla-tlanghorst commented on Apr 28, 2026

richardlau commented on Apr 28, 2026

megla-tlanghorst commented on Apr 28, 2026

richardlau commented on Apr 28, 2026

sxa commented on Apr 30, 2026

jviall commented on May 6, 2026

jasnell commented on May 7, 2026

sxa commented on May 7, 2026

MikeMcC399 commented on May 9, 2026

Manishearth commented on Oct 12, 2026

aduh95 commented on Oct 13, 2026

Manishearth commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions