Is it possible to warn rather than forbid enabling features in stable rust?

Currently, there are 2 types of rust, stable and nightly, since some features of nightly rust will never bring back to stable rust (for example, there is no stable counterpart for core::intrinsics::assume). Thus some code could never bring back to stable rust, which divide the rust code into two seperate class.

For most of the tier-1 system, we could easily install stable and nightly compiler together, thus the code with nightly features is always usable. But, for some other system, for example, my mobile phone with termux installed, could only install stable rust, and there is no way to install nightly rust.

Thus for me, I cannot enable any feature for my mobile phone.

I wonder that, could we enable feature gates in stable rust with a warning message?


Update: found a similar issue installing rust in termux: Can not install on android - target 'aarch64-linux-android' not found in channel. · Issue #2872 · rust-lang/rustup · GitHub

The solution should be install another system, such as TermuxArch or Debian, then choose the aarch64-unknown-linux-gnu triple.

There are a lot of potential reasons why people have asked for nightly features on stable Rust. But if the underlying problem for you is that you don't currently have a way to install nightly Rust on your phone, I think it'd be better to solve that problem rather than changing stable Rust to be more like nightly.

Does rustup not work on your phone? As far as I can tell, rustup should have builds for Android that work.

2 Likes

I'm using a normal rustup installation inside of a proot-distro evrironment without problems. Before I've come to the conclusion that that seemed much easier to work with than the normal termux Rust installation, I did use RUSTC_BOOTSTRAP=1 once or twice when wanting to test code with nightly features.

1 Like

assert_unchecked in std::hint - Rust (even on its track for stabilization!). That doesn't solve the base problem of not being able to use nightly features, though.

1 Like

I had tried install with rustup for several times, this is why I emphasize "for some other system", I cannot install rust nightly.

the log said that,

error: target 'aarch64-linux-android' not found in channel. Perhaps check https://doc.rust-lang.org/nightly/rustc/platform-support.html for available targets

There is no useful informations for installing the nightly build.

I suppose it might be something related to a mirror I had used, with unsetting RUSTUP_DIST_SERVER and RUSTUP_UPDATE_ROOT, I tried again, and got the same results.

full logs:

~ $ curl --proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
info: downloading installer
error: $HOME differs from euid-obtained home directory: you may be using sudo
error: $HOME directory: /data/data/com.termux/files/home
error: euid-obtained home directory: /data
error: if this is what you want, restart the installation with `-y'

Welcome to Rust!

This will download and install the official compiler for the Rust
programming language, and its package manager, Cargo.

Rustup metadata and toolchains will be installed into the Rustup
home directory, located at:

  /data/data/com.termux/files/home/.rustup

This can be modified with the RUSTUP_HOME environment variable.

The Cargo home directory is located at:

  /data/data/com.termux/files/home/.cargo

This can be modified with the CARGO_HOME environment variable.

The cargo, rustc, rustup and other commands will be added to
Cargo's bin directory, located at:

  /data/data/com.termux/files/home/.cargo/bin

This path will then be added to your PATH environment variable by
modifying the profile files located at:

  /data/data/com.termux/files/home/.profile
  /data/data/com.termux/files/home/.bashrc

You can uninstall at any time with rustup self uninstall and
these changes will be reverted.

Current installation options:


   default host triple: aarch64-linux-android
     default toolchain: stable (default)
               profile: default
  modify PATH variable: yes

1) Proceed with standard installation (default - just press enter)
2) Customize installation
3) Cancel installation
>2

I'm going to ask you the value of each of these installation options.
You may simply press the Enter key to leave unchanged.

Default host triple? [aarch64-linux-android]


Default toolchain? (stable/beta/nightly/none) [stable]
nightly

Profile (which tools and data to install)? (minimal/default/complete) [default]


Modify PATH variable? (Y/n)



Current installation options:


   default host triple: aarch64-linux-android
     default toolchain: nightly
               profile: default
  modify PATH variable: yes

1) Proceed with selected options (default - just press enter)
2) Customize installation
3) Cancel installation
>

info: profile set to 'default'
info: setting default host triple to aarch64-linux-android
info: syncing channel updates for 'nightly-aarch64-linux-android'
info: latest update on 2024-04-11, rust version 1.79.0-nightly (aa067fb98 2024-04-10)
error: target 'aarch64-linux-android' not found in channel.  Perhaps check https://doc.rust-lang.org/nightly/rustc/platform-support.html for available targets

What triple are you using?

My phone automatically choose aarch64-linux-android triple, and this triple reports an error:

error: target 'aarch64-linux-android' not found in channel.  Perhaps check https://doc.rust-lang.org/nightly/rustc/platform-support.html for available targets

I tried the same triple in my laptop, and the same error occurs.

It might be the wrong triple that stop me from installing rust nightly, but I cannot figure out what triple should I use.

1 Like

I'm using debian destro through proot-distro (proot-distro login debian …) which came pre-installed with a setup based on GitHub - phoenixbyrd/Termux_XFCE, but afaict should be a simple thing to install&use manually, too, in any termux setup. (Looks like they did also manually set up a non-root user there, no idea how required that is.)

The target triple then, using the ordinary rustup install curl script from within the shell of the proot-distro environment, turns out to be aarch64-unknown-linux-gnu.

2 Likes

Note that that particular one is actually up for stabilization as hint::assert_unchecked.

1 Like

I think in general the answer should be "we need to find a way to stabilize the things people need". Admittedly that takes time and energy from at least one or two people and doesn't address an immediate need.

2 Likes

The difficulty is that in order to become one of the people putting time and energy into stabilizing something, I first need to confirm that the experimental thing is what I need stabilized.

To do that, I need access to the experimental thing, so that I can test it and verify that I've read the documentation correctly. Once I've done that, I've got incentive to push for stabilization, and to help fix up the issues that block stability.

1 Like

The problem is that aarch64 android is Tier 2 without Host Tools -- so Rust has official libraries and stuff needed to target it, but does not have official compiler binaries that run on android. Multiple people (me included) have asked for Rust to provide host tools, but no one has volunteered to be the maintainer and go through the process to get it officially changed.

3 Likes

Right. The solution @steffahn posted allows using a non-Android toolchain on Android, which is one way to solve this. Another would be for someone to be willing to maintain aarch64-linux-android with host tools.

1 Like

how would that work? I'm assuming aarch64-linux-android already has maintainers...would there be an additional maintainer just for the host tools part? if so i might volunteer since that part seems pretty low-effort

1 Like

Yes, https://doc.rust-lang.org/nightly/rustc/platform-support/android.html has maintainers. Someone would either need to convince them to support host tools, or convince them to accept someone additional to help maintain host tools.

1 Like

Wasn't there some noise semi-recently about wanting more fine-grained stabilization than just unstable then stable? IIRC it was around stabilizing GATs being pretty painful as libraries didn't want to rewrite for something that may never ship, so it never got enough usage for the team to be comfortable releasing? (I probably messed that up)

1 Like

While I definitely don't advocate for using this in production, for playing around with features on a stable toolchain, you can use the RUSTC_BOOTSTRAP=1 env var to activate unstable features. This of course throws all stability guarantees out of the window.

2 Likes