lang/rust: Update to 1.44.0

[tobik]

Summary

Scheduled to be released on 2020-06-04.

https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1440-2020-06-04

Other port changes:

• Maybe adds LibreSSL 3.1.x support (https://bugs.freebsd.org/246332)

Test Plan

@mikael, @pkubaj: Someone will have to rebase files/powerpc64-elfv*/patch-src_librustc__mir_dataflow_generic_engine.rs if it is still required since it did not apply anymore.

11.3 i386: ok (+ consumers)
12.1 amd64: ok (+ consumers)
13.0 amd64: ok
13.0 i386: ok
13.0 aarch64: ok

[tobik]

• Remove devel/cargo-tree since it is now integrated into cargo (CC @yuri)

[mikael]

I did some experiments with 1.43.1, rust doesn't crash if std is built with this options in config.toml:

[rust]
debuginfo-level-std = 1

I don't have access to my ppc64 machine and my minicloud instance has expired...

Edit: it doesn't crash with "debuginfo-level-std = 1" and files/powerpc64-elfv*/patch-src_librustc__mir_dataflow_generic_engine.rs removed

[tobik]

• Unbreak/update devel/racer to 2.1.33
• Enable rust.debuginfo-level-std=1 on powerpc64 to fix crashes

[tobik]

• Rebase

[tobik]

Seems fine on amd64 and i386.

In D25099#552839, @mikael wrote:

I did some experiments with 1.43.1, rust doesn't crash if std is built with this options in config.toml:

[rust]
debuginfo-level-std = 1

I don't have access to my ppc64 machine and my minicloud instance has expired...

Edit: it doesn't crash with "debuginfo-level-std = 1" and files/powerpc64-elfv*/patch-src_librustc__mir_dataflow_generic_engine.rs removed

Is there an upstream issue for this?

[tobik]

Are we ready?

[pkubaj]

'patch-src_librustc__mir_dataflow_generic_engine.rs' is still needed, I rebased it and will commit it later after some testing. That said, could you give us more time than 2 days for all the testing? Please understand that I'm not paid for my work and I do it entirely in my own free time. I'm asking for at least a week before each upgrade. If you are that much short on time, remember that you can yourself fix ppc64 using ppc64-ref hosts that are available for all developers.

[tobik]

In D25099#554725, @pkubaj wrote:

'patch-src_librustc__mir_dataflow_generic_engine.rs' is still needed, I rebased it and will commit it later after some testing.

You need to bump PORTREVISION of lang/rust-boostrap for stuff like this unless you want the next bootstrap to be broken. I did so in rP538312, so no need to do it now.

Also this stuff really needs to be reported upstream and I'd like to ask you or @mikael to actually do it.

That said, could you give us more time than 2 days for all the testing?

Can you like leave a note when you a) intend to test and b) need more time with testing? I have previously said that I would wait if someone tells me to.

Note that the 2 days of testing is the window we might be able to stop/amend the release by reporting regressions upstream _early_.

Btw, Rust releases happen every 6 weeks, next one is on 2020-07-16. Patch level releases might happen 2 weeks after the last release. There is probably going to be a 1.44.1 next week (probably does not need a full test cycle though).

Please understand that I'm not paid for my work and I do it entirely in my own free time. I'm asking for at least a week before each upgrade.

I have never been paid a cent to work on FreeBSD...

If you are that much short on time, remember that you can yourself fix ppc64 using ppc64-ref hosts that are available for all developers.

Unacceptable since we cannot run Poudriere on them. How much more time should I spent on lang/rust for an arch that I do not care about?

[pkubaj]

In D25099#555300, @tobik wrote:

In D25099#554725, @pkubaj wrote:

'patch-src_librustc__mir_dataflow_generic_engine.rs' is still needed, I rebased it and will commit it later after some testing.

You need to bump PORTREVISION of lang/rust-boostrap for stuff like this unless you want the next bootstrap to be broken. I did so in rP538312, so no need to do it now.

Thanks!

Also this stuff really needs to be reported upstream and I'd like to ask you or @mikael to actually do it.

Ok, I'll do it.

That said, could you give us more time than 2 days for all the testing?

Can you like leave a note when you a) intend to test and b) need more time with testing? I have previously said that I would wait if someone tells me to.

I'm always willing to test it, but I usually need more time. The reason is that I may have $LIFE interrupting and my powerpc64 box is usually busy as well (I don't want to stop all the builds to test Rust).

Note that the 2 days of testing is the window we might be able to stop/amend the release by reporting regressions upstream _early_.

Then the only solution would be not to move the end of testing window later, but move the beginning of the window to earlier time.

Btw, Rust releases happen every 6 weeks, next one is on 2020-07-16. Patch level releases might happen 2 weeks after the last release. There is probably going to be a 1.44.1 next week (probably does not need a full test cycle though).

Please understand that I'm not paid for my work and I do it entirely in my own free time. I'm asking for at least a week before each upgrade.

I have never been paid a cent to work on FreeBSD...

I didn't say you were, but IMO requiring extensive testing done on actually two architectures (becase elfv1 and elfv2 are separate targets) on multiple ports is something that people usually take money for. Heck, I actually work as a driver tester and such tasks in my work certainly wouldn't be forced on me to do in two days.

If you are that much short on time, remember that you can yourself fix ppc64 using ppc64-ref hosts that are available for all developers.

Unacceptable since we cannot run Poudriere on them. How much more time should I spent on lang/rust for an arch that I do not care about?

It's true that the ref hosts have little usability (not only ppc64, all of them). Do you think running Poudriere builds via poudriered would be OK with you? This is something that would need to be configured by clusteradm@. poudriered is a daemon that allows regular users to queue builds. The idea would be to have poudriered on all ref hosts (not only ppc64) so that you wouldn't have to rely on your own hardware at all, other than for using SSH client.