rust: update to 1.68.0

[filnet]

No description provided.

[filnet]

Building rustbuild
   Compiling winapi-x86_64-pc-windows-gnu v0.4.0
   Compiling winapi v0.3.9
   Compiling proc-macro2 v1.0.46
   Compiling cfg-if v1.0.0
   Compiling memchr v2.5.0
   Compiling unicode-ident v1.0.0
   Compiling version_check v0.9.4
   Compiling typenum v1.15.0
   Compiling syn v1.0.102
   Compiling cc v1.0.73
   Compiling serde_derive v1.0.137
   Compiling log v0.4.17
   Compiling libc v0.2.137
   Compiling serde v1.0.137
   Compiling pkg-config v0.3.25
   Compiling windows_x86_64_gnu v0.42.0
   Compiling crossbeam-utils v0.8.14
   Compiling regex-syntax v0.6.26
   Compiling generic-array v0.14.5
   Compiling serde_json v1.0.81
   Compiling once_cell v1.12.0
   Compiling fnv v1.0.7
   Compiling itoa v1.0.2
   Compiling lazy_static v1.4.0
   Compiling ryu v1.0.10
   Compiling windows-sys v0.42.0
   Compiling bootstrap v0.0.0 (C:\M\mingw-w64-rust\src\rustc-1.68.0-src\src\bootstrap)
   Compiling unicode-width v0.1.9
   Compiling thread_local v1.1.4
   Compiling cpufeatures v0.2.5
   Compiling getopts v0.2.21
   Compiling quote v1.0.18
   Compiling cmake v0.1.48
   Compiling build_helper v0.1.0 (C:\M\mingw-w64-rust\src\rustc-1.68.0-src\src\tools\build_helper)
   Compiling hex v0.4.3
   Compiling aho-corasick v0.7.18
   Compiling bstr v0.2.17
   Compiling object v0.29.0
   Compiling lzma-sys v0.1.17
   Compiling regex v1.5.6
   Compiling fd-lock v3.0.8
   Compiling xz2 v0.1.6
   Compiling block-buffer v0.10.2
   Compiling crypto-common v0.1.3
   Compiling digest v0.10.3
   Compiling sha2 v0.10.2
   Compiling globset v0.4.8
   Compiling winapi-util v0.1.5
   Compiling filetime v0.2.16
   Compiling opener v0.5.0
   Compiling tar v0.4.38
   Compiling same-file v1.0.6
   Compiling walkdir v2.3.2
   Compiling ignore v0.4.18
   Compiling toml v0.5.9
    Finished dev [unoptimized] target(s) in 55.06s
thread 'main' panicked at 'missing llvm-tools', install.rs:215:14

[filnet]

rust-lang/rust@23a34c1

[lazka]

aarch64 failed with

2023-03-10T08:39:14.4106872Z    Compiling toml v0.5.9
2023-03-10T08:39:52.8494602Z     Finished dev [unoptimized] target(s) in 1m 30s
2023-03-10T08:39:53.5790278Z thread 'main' panicked at 'symlink_dir(C:\M\mingw-w64-rust\src\CLANGARM64\build\host => C:\M\mingw-w64-rust\src\CLANGARM64\build\aarch64-pc-windows-gnullvm) failed with The system cannot find the file specified. (os error 2)', lib.rs:599:17
2023-03-10T08:39:53.5791218Z stack backtrace:
2023-03-10T08:39:53.6152559Z    0: rust_begin_unwind
2023-03-10T08:39:53.6153115Z    1: core::panicking::panic_fmt
2023-03-10T08:39:53.6158518Z    2: bootstrap::Build::new
2023-03-10T08:39:53.6159780Z              at C:\M\mingw-w64-rust\src\rustc-1.68.0-src\src\bootstrap\lib.rs:599:17
2023-03-10T08:39:53.6160494Z    3: bootstrap::main
2023-03-10T08:39:53.6170108Z              at C:\M\mingw-w64-rust\src\rustc-1.68.0-src\src\bootstrap\bin\main.rs:50:5
2023-03-10T08:39:53.6172401Z    4: core::ops::function::FnOnce::call_once
2023-03-10T08:39:53.6175473Z              at C:\M\mingw-w64-rust\src\rustc-1.67.1-src\library\core\src\ops\function.rs:507:5
2023-03-10T08:39:53.6177928Z note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2023-03-10T08:39:53.6245978Z Build completed unsuccessfully in 0:01:31

[filnet]

aarch64 failed with

Not sure I can help here...

[filnet]

Seems like on aarch64 the previous rust is not downloaded and extracted .

A local mingw64 builds shows:

configure: run `python C:/M/mingw-w64-rust/src/rustc-1.68.0-src/x.py --help`
downloading https://static.rust-lang.org/dist/2023-02-09/rust-std-1.67.1-x86_64-pc-windows-gnu.tar.xz
################################################################################################################ 100.0%
extracting C:/M/mingw-w64-rust/src/MINGW64/build/cache/2023-02-09/rust-std-1.67.1-x86_64-pc-windows-gnu.tar.xz
downloading https://static.rust-lang.org/dist/2023-02-09/rustc-1.67.1-x86_64-pc-windows-gnu.tar.xz
################################################################################################################ 100.0%
extracting C:/M/mingw-w64-rust/src/MINGW64/build/cache/2023-02-09/rustc-1.67.1-x86_64-pc-windows-gnu.tar.xz
downloading https://static.rust-lang.org/dist/2023-02-09/cargo-1.67.1-x86_64-pc-windows-gnu.tar.xz
################################################################################################################ 100.0%
extracting C:/M/mingw-w64-rust/src/MINGW64/build/cache/2023-02-09/cargo-1.67.1-x86_64-pc-windows-gnu.tar.xz
Building rustbuild

While the failed aarch64 build shows:

2023-03-10T14:31:45.3914869Z configure: run `python C:/M/mingw-w64-rust/src/rustc-1.68.0-src/x.py --help`
2023-03-10T14:31:45.8553227Z Building rustbuild

[lazka]

(I had to revert it to unblock the queue, I hope you understand)

[filnet]

@lazka, no problems. It happened with 1.67.0 too (also because of aarch64..).

Why is aarch64 not part of CI ?

[mmuetzel]

Why is aarch64 not part of CI ?

IIUC, the reason is because there are no GitHub-hosted runners for that platform. And @jeremyd2019's runner is busy building the packages in staging.

[lazka]

And @jeremyd2019's runner is busy building the packages in staging.

It would also be a security issue since there is no job isolation; if we start building PRs the runner is tainted for staging builds.

[filnet]

I'll create a meta issue for rust...

[jeremyd2019]

Seems like on aarch64 the previous rust is not downloaded and extracted .

Correct, AFAIK there is no stage0 for that triple (quad?) so we have to build rust with the previous rust package rather than have it download a stage0. To start us off, @mati865 cross-compiled a stage0.

It would also be a security issue since there is no job isolation; if we start building PRs the runner is tainted for staging builds.

Also a security issue that people could run arbitrary code on my runner by opening a PR, potentially maliciously. With the hosted github runner github takes on that risk.

[filnet]

Seems like on aarch64 the previous rust is not downloaded and extracted .

Correct, AFAIK there is no stage0 for that triple (quad?) so we have to build rust with the previous rust package rather than have it download a stage0. To start us off, @mati865 cross-compiled a stage0.

And the related patch got removed for rust 1.67.0 ? How did 1.67.0 got built ?
See 36d92e7#diff-9d9b9deaf0bc40ce778f7bbeae62dd4b0c7a3269b7cf080ab80acfb8b5d561d9

[mati865]

Can you give me link to whole log from the build?

Seems like on aarch64 the previous rust is not downloaded and extracted .

Correct, AFAIK there is no stage0 for that triple (quad?) so we have to build rust with the previous rust package rather than have it download a stage0. To start us off, @mati865 cross-compiled a stage0.

Correct, AArch64 should build with toolchain that already exists in the repo without the need to download things.

[jeremyd2019]

Seems like on aarch64 the previous rust is not downloaded and extracted .

Correct, AFAIK there is no stage0 for that triple (quad?) so we have to build rust with the previous rust package rather than have it download a stage0. To start us off, @mati865 cross-compiled a stage0.

And the related patch got removed for rust 1.67.0 ? How did 1.67.0 got built ?

The necessary fixes were upstreamed in 1.67.0. The other part of that patch had the 'injected' cross-compiled stage0, which was out of date and no longer used anyway, due to

MINGW-packages/mingw-w64-rust/PKGBUILD

Lines 7 to 10 in 4544b4c

	_bootstrapping=yes
	if [[ $MINGW_PACKAGE_PREFIX == *-clang-aarch64 ]]; then
	_bootstrapping=no
	fi

.

We could maybe try _bootstrapping=no for other envs and see if that error reproduces, or if it really is arm-specific.

[filnet]

We could maybe try _bootstrapping=no for other envs and see if that error reproduces, or if it really is arm-specific.

I'll give it a try.

[mati865]

I cannot test locally for some time as my HDD seems to be dying.

[MehdiChinoune]

It would also be a security issue since there is no job isolation; if we start building PRs the runner is tainted for staging builds.

Also a security issue that people could run arbitrary code on my runner by opening a PR, potentially maliciously. With the hosted github runner github takes on that risk.

That could be avoided by requiring an approval to run CI. https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

[filnet]

_bootstrapping=no for other envs fails with the same error

[filnet]

Reverting rust-lang/rust@6f0fc2f fixes the issue.

[filnet]

I created an issue upstream: rust-lang/rust#109103

[filnet]

See #16189

[jeremyd2019]

OK, I was thinking maybe symlink_dir was using a deep copy to 'emulate' symlinks on Windows, like msys2-runtime does by default, but at least based on a comment it seems to use a junction. Those also require the link target to exist so that's probably the source of the file not found error.