Fix broken build on ESP-IDF caused by #115108

[ivmarkov]

@ijackson #115108 broke the build for ESP-IDF. I'm still checking whether this PR fixes everything - once I'm ready will remove the "Draft" status.

@dtolnay FYI

[rustbot]

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

[ivmarkov]

r? @dtolnay

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit b3c95c5 has been approved by dtolnay

It is now in the queue for this repository.

[ijackson]

Hi. Sorry for breaking the build.

Evidently none of these are tested in CI? Obviously my local build tests weren't sufficient, anyway. My apologies.

The modules and conditionals here are getting really quite tangled and confusing. They could do with a substantial refactor. For example, this MR introduces a third almost identical copy of someone::ExitStatus::exit_ok, along with the comment.

But given the lack of CI support it's hard to see how someone doing that refactoring could avoid just making things worse. So triplicating this already-duplicated function was probably the right answer.

[ivmarkov]

Hi. Sorry for breaking the build.

Evidently none of these are tested in CI? Obviously my local build tests weren't sufficient, anyway. My apologies.

The modules and conditionals here are getting really quite tangled and confusing. They could do with a substantial refactor. For example, this MR introduces a third almost identical copy of someone::ExitStatus::exit_ok, along with the comment.

But given the lack of CI support it's hard to see how someone doing that refactoring could avoid just making things worse. So triplicating this already-duplicated function was probably the right answer.

The ESP-IDF targets are Tier3. So no, until they stay in this tier, there is no way to test whether STD builds for those do pass via the Rust standard CI.

We catch when STD does not build for those by running our own nightly CI in the esp-rs org.

[ijackson]

We catch when STD does not build for those by running our own nightly CI in the esp-rs org.

Ah. Thanks.

I think CI approach here could do with some refinement. I appreciate that the Rust Tier system is inteded to make it easier to get code accepted in tree by reducing the possible negative consequences for general work on Rust.

However, as an MR author, in this case I would have very much welcomed pre-merge automated feedback. Frankly, nowadays I find I rely very heavily on automated curation of codebases.

Is there a way that an MR author (or other contributor) could signal that they wish to receive a report on the correctness/status of an MR on Tier 3 platforms? If not, maybe there could be one.

The Rust policy says

In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. ... unless they have opted into such messages ...

But I don't have a way to opt in :-). (Other than maybe submitting my branch as an MR in your repo too, or something.)

I think you could run a robot which watched for @-messages, saying "please send me reports about Tier 3 targets", without violating this policy. Eg I could have written @tier3 test and received a report from your CI, and maybe others' too.

If you think this would be useful, should I file a ticket somewhere requesting it? I'm not sure where that should go. Should I propose a Rust RFC given that at least some MR authors will want one message to enable for all Tier 3 platforms?