Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information.

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

cc @chriswailes

Newer versions of Android forbid the creation of hardlinks as well as Unix domain sockets in the /data filesystem

Can we find another fs to test on instead? E.g. /tmp?

Unfortunately Android devices do not have a filesystem mounted at /tmp. /data is AFAIK pretty much the only filesystem that we can rely on to be present and writable as the shell user (which adb shell commands run as).

An issue with this is that we no longer know which tests are actually run and which are skipped on Android. Maybe we should explicitly check for the android version to decide whether a test should be skipped? Or just #[ignore] the tests on Android entirely?

An issue with this is that we no longer know which tests are actually run and which are skipped on Android. Maybe we should explicitly check for the android version to decide whether a test should be skipped? Or just #[ignore] the tests on Android entirely?

I'm not sure if it's as simple as checking the Android version (I'm not sure when these restrictions were added and it might not have been at the same time on every device). Applications wouldn't be able to use these APIs successfully so there's less value in testing them, but on the other hand Rust is increasingly being used in the operating system itself. If we don't care that much about whether these tests pass on Android and we expect the existing testing on non-Android Linux to be sufficient then yes, the simplest approach is to ignore them on Android, and I've updated the patch to do that. For the operating system use case we may consider arranging to run these tests only on rooted devices, but that can come later.

Anything else needed here? As I mentioned, the tests are now ignored on Android.

Ping.

@rustbot ready

The latest upstream changes (presumably #106673) made this pull request unmergeable. Please resolve the merge conflicts.

Ping.

It seems somewhat unfortunate to be ignoring the tests entirely but...

Applications wouldn't be able to use these APIs successfully so there's less value in testing them, but on the other hand Rust is increasingly being used in the operating system itself... For the operating system use case we may consider arranging to run these tests only on rooted devices, but that can come later.

Fair enough. And ignored tests can be run explicitly. I wonder though if there could be some way for the tests to be opt-in as a group? I'm thinking something like:

#[cfg_attr(all(target_os = "android", not(test_rooted_android_device)), ignore)]

Or some other --cfg that can be passed in using rustflags. I'm not sure of the name.

What I had in mind for later was that the tests could opt in automatically by checking for getuid() == 0 and skipping if false. That way, we don't end up adding a developer-facing --cfg that we'd just remove again a few months later. Choosing the right thing to do here may take some discussion.

I do think though that as a first step we should make these tests stop failing on Android, since after several months it's already getting rather tedious to need to patch this in every time I need to run the tests.

Extremely annoying but at the same time seems fine to me.
r? @workingjubilee
@bors r+

Commit fed6fce has been approved by workingjubilee

It is now in the queue for this repository.

Testing commit fed6fce with merge a6236fa...

Test successful - checks-actions
Approved by: workingjubilee
Pushing a6236fa to master...

Finished benchmarking commit (a6236fa): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 650.76s -> 652.439s (0.26%)