rust: update to 1.65.0

[filnet]

No description provided.

[jeremyd2019]

@mati865 now it's time for me to ask what I was wondering when clangarm64 was enabled: what is the plan for building it moving forward? Turning off _bootstrapping and using the existing package (assuming we're always upgrading from an allowed version)? Are you going to be updating your stage0 for new versions? Or (hopefully) upstream will be adding them to their official list?

[mati865]

Turning off _bootstrapping and using the existing package (assuming we're always upgrading from an allowed version)?

Previously this used to be problematic because you always needed N-1 version to build N version. So You could build 1.65 using 1.64 but not rebuild 1.65 using 1.65. I think nowadays you can use N-1 or N though.
If that is the case then this would be preferred solution.

Are you going to be updating your stage0 for new versions?

No problem for me.

Or (hopefully) upstream will be adding them to their official list?

The only problem here is getting machines where that would run. Unlike many other projects Rust builds each commit for every target/host that is enabled to build them. So it needs a lot of relatively fast runners and currently they are already struggling.

[jeremyd2019]

Yeah, windows arm64 runners are an issue 😬

[lazka]

So, OK to merge?

[jeremyd2019]

I expect clangarm64 needs more work before it would build. I didn't see the patches for it updated here, so they most likely won't apply.

[lazka]

oh, I see

[lazka]

(We could also create a arm64 specific pkgbase of this, so it can be updated at a different pace?)

[jeremyd2019]

The stage0.json hunk will either need to be updated with a new build from @mati865, or else drop it and switch _bootstrapping=no for arm64 to use the existing packaged rust to build the new version. I'm thinking I'll try the latter and see what happens.

[jeremyd2019]

switch _bootstrapping=no for arm64 to use the existing packaged rust to build the new version. I'm thinking I'll try the latter and see what happens.

Getting an error LLVM ERROR: dwo only supported with ELF and Wasm. I turned up rust-lang/rust#101071, and a TODO comment about windows-gnu

[mati865]

We should probably add the same two lines that are under Todo in gnu targets spec to gnullvm targets spec.

[jeremyd2019]

I've got a build running with the following patch. It's gotten further than the last run.

--- rustc-1.65.0-src/compiler/rustc_target/src/spec/windows_gnullvm_base.rs.ori2022-11-02 14:36:24.000000000 +0000
+++ rustc-1.65.0-src/compiler/rustc_target/src/spec/windows_gnullvm_base.rs    2022-11-05 20:16:01.345559900 +0000
@@ -1,4 +1,5 @@
-use crate::spec::{cvs, LinkerFlavor, TargetOptions};
+use crate::spec::{cvs, DebuginfoKind, LinkerFlavor, SplitDebuginfo, TargetOptions};
+use std::borrow::Cow;

 pub fn opts() -> TargetOptions {
     // We cannot use `-nodefaultlibs` because compiler-rt has to be passed
@@ -34,7 +35,10 @@
         eh_frame_header: false,
         no_default_libraries: false,
         has_thread_local: true,
-
+        // FIXME(davidtwco): Support Split DWARF on Windows GNU - may require LLVM changes to
+        // output DWO, despite using DWARF, doesn't use ELF..
+        debuginfo_kind: DebuginfoKind::Pdb,
+        supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]),
         ..Default::default()
     }
 }

[jeremyd2019]

clangarm64 built successfully with that patch. I'll leave it to @mati865 to send it upstream, I imagine there are a few of the fixes for gnullvm that need to be sent.

[mati865]

Yeah, windows arm64 runners are an issue 😬

I don't think it's the problem. AFAIK Rust had special runners provided by Microsoft for a long time. The problem is more about getting more runners.

clangarm64 built successfully with that patch. I'll leave it to @mati865 to send it upstream, I imagine there are a few of the fixes for gnullvm that need to be sent.

I'm sending them separately (some are already sent) so you can go ahead and open PR.