RFC: Target extension

[semarie]

Rendered

[semarie]

it seems macos use something like that to provide to llvm the OS version. It is using MACOS_DEPLOYEMENT_TARGET env variable to force a specific version.

So I assume a RFC isn't necessary any more to propose something similar for OpenBSD ?

[gnzlbg]

This number has increased.

[gnzlbg]

@Centril which team is responsible for this ? @rust-lang/compiler or @rust-lang/libs ? And what would be required for this to move towards FCP ?

[Centril]

I'll have a look later today.

[Centril]

Having reviewed the RFC, I think it is clearly both a compiler team RFC (because changes to target specs wrt. backend purposes) and a language team (because new cfg flags are added).

However, @nikomatsakis's noted:

After some discussion in the @rust-lang/lang meeting, we decided that libs would be a better, if not ideal, fit for this RFC. Therefore, re-assigning to T-libs.

Thus I will let T-libs remain but also add T-compiler + T-lang.

[Centril]

I think perhaps @nagisa would be a good fit to think about the RFC deeply. =)

The compiler team should probably take the lead here.

[retep998]

It would be nice if the RFC covered targets with multiple independent versions. For example, Windows, where the VC++ version is independent of the OS version. The VC++ version would need to be tied into a system for doing VC++ detection in one place and ensuring everything uses the same version. For the windows version it is even worse because in addition to setting the supported windows version and adding a manifest to declare that to Windows, there is also the windows sdk version which has its own breaking changes. For drivers especially, there are breaking changes between each build of windows.

[semarie]

@retep998 for what I know of Windows environment, VC++ version would be in environment version. So you could have a triple like x86_64-pc-windowsX.Y-msvcZ.T. According to the RFC, it would define target_os_version = X.Y and target_env_version = Z.T.

but regarding rust ecosystem (rustup for example), I doubt it would be interesting to provide several targets for all environements.

maybe some discussion could occurs on target selection, based on what the user provide (x86_64-pc-windowsX.Y-msvcZ.T for example), and which target rustc will select (if only x86_64-pc-windows-msvc is available for example). The point is opened in "unresolved question" section.

[pnkfelix]

Discussed in lang team backlog bonanza, where we observed that this is likely to be small and self-contained, important for specific audience (BSD), and fits the Rust's goal of “low-level capabilities."

The lang team concluded that if there is a contributor motivated to do this work here, then this is a good candidate for a major change proposal (MCP) and a dedicated project group to land a prototype implementation first (and we'll worry about the final design later, before stabilization). That is, we think there are important questions here that are more likely to be answered via direct tinkering, rather than via iterating on an abstract RFC design document.

So we are going to close this RFC and ask that you please file a lang team MCP, and then see if you can get a project group to coalesce around that.

• (The lang team did also note offhand that this might be better suited as a T-compiler proposal rather than going through T-lang. It is a gray area at best. So you are probably safe filing the MCP with either team.)

@rfcbot fcp close

[rfcbot]

Team member @pnkfelix has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @KodrAus
• @cramertj
• @dtolnay
• @eddyb
• @estebank
• @joshtriplett
• @matthewjasper
• @nagisa
• @nikomatsakis
• @oli-obk
• @petrochenkov
• @pnkfelix
• @scottmcm
• @sfackler
• @varkor
• @wesleywiser
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[pnkfelix]

(I'm going to check off the members of the lang team since they agreed to the close proposal during aforementioned backlog bonanza. But I will leave other teams unchecked until at least after tomorrow's T-compiler triage meeting.)

Update: After announcing my intentions here at today's compiler team meeting, I have checked off the T-compiler team members too.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC is now closed.