Pre-RFC: `usize` semantics

Right now one can simulate this with a compile-time assertion, either using static_assertions or something else, to prevent the code from compiling in platforms it doesn't support.

What would be even better is to lift this information to Cargo, so that depending on an incompatible crate (or even, enabling an incompatible combination on feature flags on an otherwise compatible crate) would result in an error at Cargo level, rather than ultimately be turned into a compiler_error!() or something.

I think the largest user base for this feature would be people using Rust in a no_std environment, that would get better error messages if they accidentally depend on crates that don't work without the stdlib.

Tier 3 targets are not available on stable either way. Without a pre-compiled standard library there is no way to use a target without unstable features and tier 3 targets don't provide a pre-compiled standard library.


wouldn't they be available if building rust stable from source? i'd guess they're merely not available via rustup, rather than not buildable from source.

It would. We could declare that as being outside our stability guarantee though. There are multiple options in config.toml that are behind -Z rustc flags already.

1 Like

Assertions and compile errors won't give you impl From<u32> for usize and impl From<usize> for u64.

From some of this discussion it seems like there are a lot of unknowns about the proposal here. Perhaps the best path forward would be something like the following:

  1. Assume this Pre-RFC is what we want to go with, without actually accepting it
  2. Add CHERI as a tier 3 target, which likely will not build out of the box
  3. Over time, make the changes needed to make the CHERI target work
  4. Write an actual RFC for acceptance based on this proposed RFC, modified by what was learned through CHERI trial and error

The T3 target docs say "Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work." Something that doesn't work on stable but happens to (maybe) work on nightly already fits this by my understanding, so I don't see much added benefit to blocking a CHERI target on a new -Znightly-targets config option.

1 Like

but quite a few tier 3 targets do work on stable, as long as you build from source.

You need at least libcore for that, how do you get that? What do you mean by "build from source" -- build what from source? If you mean building rustc from source, @bjorn3 already replied to that. Using a custom config.toml you are quickly entering unstable territory.

Also, how does "quite a few targets work" contradict "they may or may not work"? (You started your reply with "but" so it sounds like you intend to contradict something.)

you get libcore from: rust/library/core at 1.78.0 · rust-lang/rust · GitHub (or whatever stable version you're trying to use)

If all you're doing in config.toml is enabling additional targets, I think people would generally consider that to be also stable if they're building from a stable version of rust's source. After all, they aren't explicitly labeled experimental or require an enable-nightly-features-please flag, there merely not built by default.

it doesn't really contradict what he said, but it does mean there isn't really a barrier where you notice "entering-unstable-land" when building from stable's source. Having such a barrier is what was wanted for CHERI targets.

Given that tier 3 targets are already pretty unstable as noted above, it seems unclear that CHERI is the right place to put the barrier here.

they aren't explicitly labeled experimental or require an enable-nightly-features-please flag, there merely not built by default.

They are explicitly labeled as "they may or may not work" on the page you have to consult to figure out what you can even put there in the build config.


So instead of making semantic changes to the entire language now, we limit them to a tier 3 CHERI target and see how that goes? If it gives us a way to unblock work toward an experimental CHERI target and reassure people's worries about semantic changes, then it sounds good to me! Assuming it works out, we can then come back and talk about how to fit the changes into the rest of the language.

We could gate it behind a compiler flag too, if needed, but I agree with @tgross35 and @RalfJung that that doesn't seem very useful. Stopping someone accidentally using a highly experimental target makes sense, but surely needing to compile the standard library will already be enough to make someone well aware that they need to know what they're doing for that target?


AFAIK the difference between usize == size_t and usize == intptr_t is still indistinguishable on all stable Rust targets, so declaring usize == size_t won't break anybody in practice.

To avoid future breakage of targets where this does makes a difference and intptr_t > size_t, while their experimental implementations still assume usize == intptr_t, their target triples could be renamed to something else, e.g. with an -oversized_usize suffix. This way they won't be blocked from being added to Rust someday with usize == size_t default.

1 Like

I don't see any reason that adding a CHERI target needs to be blocked on having a concrete answer to this semantics question, honestly it will likely help to give us a better picture of what our pointer/integer types actually mean.

At this point you could probably start a minimal PR to add the target (recent example) and get moving things toward the action phase. At least that would help get to a more definitive answer for what the teams see as blocker or not.

1 Like

Instead of spending a lot of time splitting hairs on how to best solve your problem given that the compiler team has rejected the proposal for -Zexperimental-target and presenter an alternative you deem unsatisfactory, why not just come to the compiler team and talk about your problem? I'm sure the compiler team is interested in solving your problem, and the consensus in the MCP was that just adding the target was a satisfactory solution, so if it's not then please come back!

1 Like

Just for clarity, what is the unsatisfactory alternative? Is it just adding the target as a tier 3?

I'm supportive of adding a new target tier 3 target aarch64-unknown-freebsd-purecap (which is the same as the CHERI LLVM target for CHERI BSD) and not adorning the compiler with any further options.