Skip to content

Add OpenBSD -current release version to target_env #160739

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
dybucc wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Add OpenBSD -current release version to target_env #160739

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c942164
chore: wip
dybucc Aug 7, 2026
00af586
chore: wip
dybucc Aug 10, 2026
ce07dd3
chore: wip
dybucc Sep 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion compiler/rustc_target/src/spec/base/openbsd.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,9 @@
use crate::spec::{FramePointer, Os, RelroLevel, TargetOptions, TlsModel, cvs};
use crate::spec::{Env, FramePointer, Os, RelroLevel, TargetOptions, TlsModel, cvs};

pub(crate) fn opts() -> TargetOptions {
TargetOptions {
os: Os::OpenBsd,
env: Env::OpenBsdCurrent,
dynamic_linking: true,
families: cvs!["unix"],
has_rpath: true,
Expand Down
1 change: 1 addition & 0 deletions compiler/rustc_target/src/spec/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2045,6 +2045,7 @@ crate::target_spec_enum! {
Nto71 = "nto71",
Nto71IoSock = "nto71_iosock",
Ohos = "ohos",
OpenBsdCurrent = "openbsd8.0",
Relibc = "relibc",
Sgx = "sgx",
Sim = "sim",
Expand Down
16 changes: 15 additions & 1 deletion src/doc/rustc/src/platform-support/openbsd.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,21 @@ The target names follow this format: `$ARCH-unknown-openbsd`, where `$ARCH` spec

Note that all OS versions are *major* even if using X.Y notation (`6.8` and `6.9` are different major versions) and could be binary incompatibles (with breaking changes).

> [!IMPORTANT]

@tgross35 tgross35 Sep 7, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though the contents of this block are more relevant for rustc developers (and should move to a comment as noted), please do add user-facing documentation about what version is supported (-current) and how target_env works

View changes since the review

> These targets, if supported by the next OpenBSD `-current` release
> channel, need to update the `rustc_target::spec::Env` type under
> `compiler/` in the `rust-lang/rust` repository whenever a new OpenBSD
> version is released. If unsupported, the prior `Env` data constructor
> shall need to remain, while a new data constructor for the new release
> upstream shall be created for all targets that are still supported
> upstream.
>
> That should reflect the `-current` release channel, which is always
> one version above the latest `-release` channel version.
>
> One must also update the `src/librustdoc/clean.rs` file with the
> relevant formatted string providing a public view of this
> `target_env` value.

@tgross35 tgross35 Sep 7, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be a markdown comment, as it's relevant to the people updating the doc rather than people reading it. Just make it a numbered todo list to keep things simple, and you can probably say "note that if OpenBSD stops supporting a platform we may want to freeze its target_env" without describing the specifics of what that looks like.

Also "data constructors" is kind of an unusual term, they're just enum variants.

View changes since the review


## Target Maintainers

Expand All @@ -30,7 +45,6 @@ Further contacts:

Fallback to ports@openbsd.org, OpenBSD third parties public mailing-list (with openbsd developers readers)


## Requirements

These targets are natively compiled and could be cross-compiled.
Expand Down
1 change: 1 addition & 0 deletions src/librustdoc/clean/cfg.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -723,6 +723,7 @@ fn human_readable_target_env(env: Symbol) -> Option<&'static str> {
Nto71 => "QNX SDP 7.1",
Nto71IoSock => "QNX SDP 7.1 with io-sock",
Ohos => "OpenHarmony",
OpenBsdCurrent => "OpenBSD -current (8.0)",
P1 => "WASIp1",
P2 => "WASIp2",
P3 => "WASIp3",
Expand Down
2 changes: 1 addition & 1 deletion tests/ui/check-cfg/well-known-values.stderr
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`

@tgross35 tgross35 Aug 12, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

View changes since the review

@dybucc dybucc Aug 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm looking into this.

@dybucc dybucc Aug 14, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@dybucc dybucc Aug 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. Version-typed cfgs rfcs#3905 ↩

@tgross35 tgross35 Sep 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's anything in RFC territory or changes to the parser needed, just an update to also check a (for now) hardcoded predicate for OpenBSD at

rust/compiler/rustc_attr_parsing/src/attributes/cfg.rs

Lines 206 to 224 in f0bbd8d

match cx.sess.check_config.expecteds.get(&name) {
Some(ExpectedValues::Some(values)) if !values.contains(&value.map(|(v, _)| v)) => cx
.emit_lint_with_sess(
UNEXPECTED_CFGS,
move |dcx, level, sess| {
check_cfg::unexpected_cfg_value(sess, (name, name_span), value)
.into_diag(dcx, level)
},
span,
),
None if cx.sess.check_config.exhaustive_names => cx.emit_lint_with_sess(
UNEXPECTED_CFGS,
move |dcx, level, sess| {
check_cfg::unexpected_cfg_name(sess, (name, name_span), value).into_diag(dcx, level)
},
span,
),
_ => { /* not unexpected */ }
}
. But that can be a followup, no need to change here.

= note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg.html> for more information about checking conditional configuration

warning: unexpected `cfg` condition value: `_UNEXPECTED_VALUE`
Expand Down
Loading