rust 1.74.0

[ZhongRuoyu]

Created with brew bump-formula-pr.

• resource blocks have been checked for updates.

[Bo98]

Requires 10.12 as of this release so maybe worth marking as depends_on macos: :sierra given how popular Rust is: https://blog.rust-lang.org/2023/09/25/Increasing-Apple-Version-Requirements.html

[Bo98]

Looks like it regressed in rust-lang/rust@bb8c497.

Also looks like it might been secretly fixed today in among this mega commit: rust-lang/rust@db3e2ba#diff-5a1e05f2688d271039171a547d407d0c8a96715ee64d35562fc76b4c9a874303L595 (see the small change to the src/bootstrap/src/core/build_steps/compile.rs).

It isn't clear to me why macOS 12 was always different though. Pretty difficult to pick through the build system, but I've not found anything obvious yet.

[ZhongRuoyu]

Thanks @Bo98! Indeed that seems to be the issue. Let's see if it builds with the compile.rs patch...

[Porkepix]

Thanks @Bo98! Indeed that seems to be the issue. Let's see if it builds with the compile.rs patch...

If it only fails to build on 12-arm64, shouldn't the patch only be applied there? (Don't know if it's possible nor if it's what should be done, can't judge what the patch and original commit changed)

[ZhongRuoyu]

If it only fails to build on 12-arm64, shouldn't the patch only be applied there?

It's possible but either should work; the patch should have no impact on the other platforms since the error didn't occur.

[Bo98]

If it only fails to build on 12-arm64, shouldn't the patch only be applied there?

Speaking generally:

I say to apply the patch everywhere. If a patch is for some reason considered unsafe to apply everywhere, then such a patch should probably not be included at all.

In this case, upstream have patched it for all, unconditionally, so we'll trust that.

[chenrui333]

looks good so far 🤞

[Porkepix]

It's curious how it have so few dependents to test on Linux compared to mac? Less than ten, finished within less than 10 minutes while 16H later it still have work to do on ARM jobs. Is the Linux job not considering CI-build-dependents-from-source?

Also, question: considering it does anyway the job of building these formulas when this tag is present, why not have those formulas benefiting of a compilation with the last compiler, to get rid of potential bugs, security issues and so on? This tag implies the build is happening anyway.

[Bo98]

Is the Linux job not considering CI-build-dependents-from-source?

No it doesn't. I don't remember the historical reasons for this. It will do any Linux-only formulae however.

That check is largely for API compatiblity checks so it might be worth making it split those among runners.

Also, question: considering it does anyway the job of building these formulas when this tag is present, why not have those formulas benefiting of a compilation with the last compiler, to get rid of potential bugs, security issues and so on

This is probably also reasonable. Or at least for Rust & Go specifically.

Though it would also mean that it would have to test the dependents of those formulae too so it will make it even longer.

[Porkepix]

Is the Linux job not considering CI-build-dependents-from-source?

No it doesn't. I don't remember the historical reasons for this. It will do any Linux-only formulae however.

That check is largely for API compatiblity checks so it might be worth making it split those among runners.

Also, question: considering it does anyway the job of building these formulas when this tag is present, why not have those formulas benefiting of a compilation with the last compiler, to get rid of potential bugs, security issues and so on

This is probably also reasonable. Or at least for Rust & Go specifically.

Though it would also mean that it would have to test the dependents of those formulae too so it will make it even longer.

I'd say any compiled language actually, so gcc & llvm for a couple of other formulas languages, and all the less popular ones that either doesn't come to mind either I'm not sure if they're compiled or interpreted?

But yeah if this check is split among the runners then that would also mean not everything for every platform would be built. It already doesn't build most of them for Linux looking at what you said.

[ZhongRuoyu]

Source build failures

• gping (logs): error[E0283]: type annotations needed
• (x86_64) gptline (logs): src/libImaging/Jpeg2K.h:11:10: fatal error: 'openjpeg.h' file not found
• leaf-proxy (logs): error[E0425]: cannot find value `VERSION_3_2_0` in crate `protobuf`
• solana (logs): error: assigning to `&T` is undefined behavior, consider using an `UnsafeCell`
• tremor-runtime (logs): error: no rules expected the token `:`

Pre-existing issues

• flux (logs): error: private item shadows public glob re-export; fix: libflux build error on >= rust-1.72.0 influxdata/flux#5440
• gluon (logs): error[E0308]: mismatched types; Support rust 1.70.0 gluon-lang/gluon#951
• grin-wallet (logs): error: variable does not need to be mutable; Fix build error with Rust 1.71.0 mimblewimble/grin-wallet#684
• influxdb (logs): error: private item shadows public glob re-export
• influxdb@1 (logs): error: private item shadows public glob re-export
• kapacitor (logs): error: private item shadows public glob re-export
• (x86_64) pushpin (logs): include/GFp/check.h:27:11: fatal error: 'assert.h' file not found
• (x86_64) watchman (logs): ld: Undefined symbols; rust 1.66.0 #118242 (comment)

Checksum mismatch

• neovide (logs)
• wasmer (logs)

Transient failures

• (14-arm64) boringtun (logs): Timeout::Error: execution expired
• (12-x86_64) tcl-tk (logs): Error: bad URI(is not URI?): "https://downloads.sourceforge.net/project/incrtcl/[incr%20Tcl_Tk]-4-source/itk%204.1.0/itk4.1.0.tar.gz?download&failedmirror=deac-riga.dl.sourceforge.net"

[ZhongRuoyu]

Failures are non-blocking; merging now

[chenrui333]

I will followup with those failures (after all, rust is just build dependency for many formulae)

[github-actions]

@chenrui333 has requested bottles to be published to this PR.