Re: Assert in rust_target.gni

[Łukasz Anforowicz]

/cc @rust...@chromium.org 

Thank you for your email and for raising this issue.

On Sat, May 31, 2025 at 5:48 AM Yngve N. Pettersen <yn...@vivaldi.com> wrote:

Hi,

I am presently updating Vivaldi to Chromium 138, and have just encountered
an issue with our executable signing system for Windows caused by the
enable_rust assert in rust_target.gni that you added a month ago.

Ack.  I think you are referring to https://crrev.com/c/6492407/2/build/rust/rust_target.gni 

Our signing system builds and signs a mini_installer executable, the GN
file for this target includes at least one target from //base, and that
causes an assert in the above mentioned target.

Could you share which `//base` target you depend on?

We have specified enable_rust as false for this system since it is as far
as we can tell not necessary for the mini installer target (and enabling it
breaks GN elsewhere, although we might conceivably be able to work around
that; but we are also building older versions of Vivaldi that would not
have that kind of workaround, and which might break in other ways).

What it looks like is that //base uses Rust GN templates, without
conditioning it on enable_rust (or the templates aren't changing behavior
based on that)

Yes - in theory some subset of `//base` targets and/or `//base/.../*.gn` files could explicitly handle the `!enable_rust` situation.  OTOH my initial thought is that if you depend on `//base`, then you also need to ensure that `enable_rust = true`.  It is possible that a part/subset of `//base` doesn't currently depend on Rust, but we can't guarantee that things will stay this way - it is easiest to have a blanket assumption that anything in `//base` can have a Rust dependency.  Still, this is just an initial reaction, and maybe I should change my mind after learning more details.

FWIW this has come up in the past (e.g. in https://crbug.com/374672760) and back then we have taken a position that Chromium engineers (including ones making changes in `//base`) can assume that Rust is available going forward "everywhere".  I think the only exception to this rule is the `//build` directory, which has to work without Rust for projects depending on `//build` that don't yet require Rust.  (Targets built using the NaCl toolchain are another exception, but IIUC this toolchain should be removed "soon".)    

 

My immediate solution will probably be to disable the assert, but I would
suggest that you make the GN files non-rust-safe.

--
Sincerely,
Yngve N. Pettersen
Vivaldi Technologies AS

[Yngve N. Pettersen]

Hi again,

BTW, I just hit another assert in that template, due to enable_rust_cxx now being set to enable_rust, not build_with_chromium as before.

Forcing it true for the signing system in args.gn (same way we  disble rust) works around the issue, and is compatible with the older versions of Vivaldi

On Saturday, 31 May, 2025 21:15:00 (+02:00), Yngve N. Pettersen wrote:

Hi, the top target we depend on for the signing (for windows) is

  //chrome/installer/mini_installer:mini_installer_archive

"mini_installer_sources" depends on //base:clang_profiling_buildflags , which is AFAICT the only base target the installer itself depends on, but there is also the unit test target that also depends on a couple of base targets.

AFAICT the installer itself does not depend on any Rust-based functionality, or even anything else //base , it "just" needs a buildflags target (the tester is a different case, but it could be that it breaks GN processing, despite not being referenced).

[Yngve N. Pettersen]

Hi, the top target we depend on for the signing (for windows) is

  //chrome/installer/mini_installer:mini_installer_archive

"mini_installer_sources" depends on //base:clang_profiling_buildflags , which is AFAICT the only base target the installer itself depends on, but there is also the unit test target that also depends on a couple of base targets.

AFAICT the installer itself does not depend on any Rust-based functionality, or even anything else //base , it "just" needs a buildflags target (the tester is a different case, but it could be that it breaks GN processing, despite not being referenced).

On Saturday, 31 May, 2025 20:34:30 (+02:00), Łukasz Anforowicz wrote:

[Łukasz Anforowicz]

FWIW I've opened https://crbug.com/422235175 to track the problem related to the `//base:clang_profiling_buildflags` target.

[Yngve N. Pettersen]

Thanks.

I'd might have phrased one part differently, though; I would have either said targets that does not need rust, or that work without rust.