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.
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:
Assume this Pre-RFC is what we want to go with, without actually accepting it
Add CHERI as a tier 3 target, which likely will not build out of the box
Over time, make the changes needed to make the CHERI target work
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.
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.)
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.
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.
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!
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.
Having usize == u64 on CHERI would likely break some code, but I'm pretty sure that having CHERI use usize == u128 would also break some code. I mean, there's almost surely a non-zero amount of Rust code that doesn't work on targets with usize == u32, and those targets already exist!
I'm of the opinion that usize is more common than necessary and that there's a lot of code that accidentally depends on the pointer width as a result. But it is kind of late to change how slice indexing works now
In my understanding, the problem is not size of usize per se. The main problem is int2ptr casts, which simply do not work on CHERI. The proposal to use 128-bit usize, in my opinion, is just a hack, which does not solve the root issue. (There is also unsafe code which assumes pointer size being equal to word size, but such code is a relative minority)
This is why I suggested above that we primarily should promote the strict provenance APIs and disable by default raw int2ptr (and ptr2int while we at it) casts in a future edition. For one edition it may be worth to leave the door open and allow an explicit opt-in for crates dependent on raw casts, but in the edition after that it could be disabled for good (depending on usage statistics). CHERI targets then would be supported only by crates which have migrated to these new editions (we also could have experimental support with panicking int2ptr casts).
We absolutely should not deprecate/remove expose_addr/from_exposed_addr (and the equivalent as-cast behavior) from other targets. CHERI would need to be something like the primary development target for most new programmers for that to be reasonable, not a very experimental and new target. CHERI for now can entirely reasonably just not support some moderately-rare parts of rust that crates generally assume exist.
Whether or not size_t==intptr_t should remain in the "reasonable assumptions you can make in unsafe rust that isn't supposed to be particularly platform-specific" is debatable, expose is not imo. (And then there's "[MaybeUninit<u8>; size of T] is a safe transmute for any T", which CHERI also cannot support and seems like the most likely to be guaranteed by any rust spec of the three)
I disagree. Yes, there are valid usecases for int2ptr casts in systems programming. The most obvious example is bare-metal programming where description of hardware registers is given as plain integers. But I think a better way for modelling this is using a some kind of "master pointer", from which those low-level pointers will be derived.
CHERI's popularity is important, but even without it, a proper provenance model and tracking is desirable for compiler on non-CHERI targets. And the with_exposed_provenance docs clearly state that the required "guessing" introduces a lot of complexity, which ideally should not be present.
At the very least, with_exposed_provenance should be heavily discouraged in most cases and the best way to do it is to require an explicit opt-in from crates.
You mean casting &T to &[MaybeUninit<u8>; size of T]? Why wouldn't it be supported by CHERI? A CHERI machine does not track any type information, it only tracks pointer bounds (there are also some aligment stuff to allow compressed representation of pointers, which I do not fully understand, but I don't think it's important here) and whether a given 128-bit memory location can be used as a pointer or not.
I think I agree with the "should not deprecate" argument in the short term, but one of the long-term goals of CHERI is to bring formal pointer semantics to hardware generally. From that perspective, we should probably prepare for deprecating int-to-pointer casts at some indefinite point in the future.
My reasoning is that any unsafe pointer code that works on CHERI ought to have a high probability of working everywhere else. And more importantly that code should be easier to verify. Even if CHERI won't be common enough to become the default for developers in the near term, it would still be an ideal aspirational target. And if the pointer provenance in hardware concept catches on in some years, the "CHERI incompatible" code will have to be rewritten anyway.