Add OpenBSD -current release version to target_env - #160739
Conversation
This comment has been minimized.
This comment has been minimized.
| Nto71 => "QNX SDP 7.1", | ||
| Nto71IoSock => "QNX SDP 7.1 with io-sock", | ||
| Ohos => "OpenHarmony", | ||
| OpenBsd => "OpenBSD -current", |
There was a problem hiding this comment.
I'd name the variant OpenBsdCurrent and update this name to maybe OpenBSD -current (7.9)
| @@ -156,7 +156,7 @@ warning: unexpected `cfg` condition value: `_UNEXPECTED_VALUE` | |||
| LL | target_env = "_UNEXPECTED_VALUE", | |||
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |||
| | | |||
| = note: expected values for `target_env` are: ``, `gnu`, `macabi`, `mlibc`, `msvc`, `musl`, `newlib`, `nto70`, `nto71`, `nto71_iosock`, `ohos`, `p1`, `p2`, `p3`, `relibc`, `sgx`, `sim`, `uclibc`, and `v5` | |||
| = note: expected values for `target_env` are: ``, `gnu`, `macabi`, `mlibc`, `msvc`, `musl`, `newlib`, `nto70`, `nto71`, `nto71_iosock`, `ohos`, `openbsd7.9`, `p1`, `p2`, `p3`, `relibc`, `sgx`, `sim`, `uclibc`, and `v5` | |||
There was a problem hiding this comment.
We may want to allow any openbsdM.m for M.m > 7.9 for the unexpected cfg lint, so e.g. this version of Rust doesn't emit a warning if it sees target_env = "openbsd8.0".
If that's easy then I think you could do it here but if not, can be a followup.
There was a problem hiding this comment.
I'm looking into this.
There was a problem hiding this comment.
I think I have some basics done to accomplish this. The current
implementation is far from ideal, but I preferred to have an initial
overview of it.
In rustc_session, there lives functionality to both address cfgs
and check-cfg for those cfgs. The data structures backing value
validation, though, seem quite primitive in nature.
I've tried to go for something simple (that doesn't yet build.) The
enumeration that is used for expected values in cfgs, namely,
ExpectedValue, has been extended with one more variant.
The two prior variants covered the possibility for (1) some cfg to
be capable of taking any value, or for (2) a cfg to take in a
pre-defined set of values. The new variant allows setting a bound.
This bound is currently limitted to all values above some known value,
which is the usecase we have in the MCP, but I think it could be
extended easily.
Then back in the rustc_target::spec::Env, I extended this type with
a new method that returns a decimal representation of the OpenBSD
variant. This then gets interned back at rustc_session::config::cfg.
I've yet to look into how do the set of expected values get parsed in
rustc_session, so for now this only sets up some infrastructure.
I've yet to work on changing the actual checking logic.
There was a problem hiding this comment.
This change is not feasible. It possibly needs an RFC prior to
implementation, as it's a non-trivial change that would require
modifying the way cfg values are parsed.
Working around it only for OpenBSD while using the
ExpectedValues::Any variant of the type in charge of holding
expected values is a subpar solution.
I think the need we have in this instance could be fulfilled once the
versioned cfgs RFC 1 gets implemented. That can be followed up by
another RFC that extends typing from whole cfgs to more fine-grained
cfg variants (like Env::OpenBsdCurrent here.)
Footnotes
| Nto71 = "nto71", | ||
| Nto71IoSock = "nto71_iosock", | ||
| Ohos = "ohos", | ||
| OpenBsd = "openbsd7.9", |
There was a problem hiding this comment.
Add this version to https://doc.rust-lang.org/beta/rustc/platform-support/openbsd.html. Put a comment by it in the markdown file as well saying that the target_spec_enum should be updated when that version is bumped (and anything else that needs it)
Also, isn't the current -current 8.0?
There was a problem hiding this comment.
I think that should be done now. I'm not sure how to handle the
possibility for some target to still have Rust support but be dropped
out of OpenBSD support.
What value should they use then? We only ever target the latest
-current, but that hypothetical target would be stuck in some older
-current. They can't just abide by the general OpenBSD spec.
Yes, the current -current is 8.0. That's fixed now.
There was a problem hiding this comment.
Could you give an example of what OpenBSD and Rust version combo would be problematic? I'm not sure what the circumstances would be, given Rust support moves every 6 weeks.
There was a problem hiding this comment.
An example would be any platform that has been deprecated in upstream
OpenBSD in the next ten years, and for which we could have Rust
support.
Suppose the powerpc64-unknown-openbsd Rust target, which corresponds
with the PowerPC architecture family, now isn't supported anymore in
OpenBSD 9.0. And yet we do want to still provide support for it in
Rust.
What value of the rustc_target::spec::Env should we provide for this
target in future rustc releases (starting from the nightly that would
ship support for OpenBSD 9.0?) Should they use Env::Unspecified?
Or should we immediately drop newer Rust support for any target that
gets dropped out of upstream OpenBSD support?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
how it was used.
Draft PR to add support for
target_envvalues in OpenBSD to carry their-currentrelease channel version number.This is meant to be the associated implementation for
rust-lang/compiler-team#1018.
Unlike the proposed implementation plan in the MCP, no specific target specs
have been modified. The base specification currently serves just fine for all
supported OpenBSD targets.
If at some point in the future, some OpenBSD release drops support for a current
Rust target, the target-specific module can be modified to avoid relying on the
default
Envvalue.