Skip to content
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.

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

Tracking issue for RFC 1868: A portability lint #41619

Open
4 tasks
aturon opened this issue Apr 29, 2017 · 17 comments
Open
4 tasks

Tracking issue for RFC 1868: A portability lint #41619

aturon opened this issue Apr 29, 2017 · 17 comments
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. E-help-wanted Call for participation: Help is requested to fix this issue. finished-final-comment-period The final comment period is finished for this PR / Issue. Libs-Tracked Libs issues that are tracked on the team's project board. S-tracking-unimplemented Status: The feature has not been implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Apr 29, 2017

This is a tracking issue for the RFC "A portability lint" (rust-lang/rfcs#1868).

Steps:

Unresolved questions:

  • It's not clear what the story should be for a library like libc, which currently involves intricate uses of cfg. We should have some idea for how to approach such cases before landing the RFC.
@aturon aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 29, 2017
@durka
Copy link
Contributor

durka commented Jul 8, 2017

cc #43086

@SimonSapin
Copy link
Contributor

When this is implemented, reconsider ExactSizeIterator for Range<_> and RangeInclusive<_>: #43086 (comment)

@eternaleye
Copy link
Contributor

eternaleye commented Jul 20, 2018

Just encountered a relevant research project - their work may have aspects we can reuse: http://fosd.net/TypeChef

TypeChef is a research project with the goal of analyzing ifdef variability in C code with the goal of finding variability-induced bugs in large-scale real-world systems, such as the Linux kernel with several thousand features (or configuration options).

@Ericson2314
Copy link
Contributor

Ericson2314 commented Jul 23, 2019

[Hopefully this doesn't count as inappropriate advertising!] I'll be 1 half of a 2 person talk at the HIW at ICFP reviewing some of the literature. I was certainly inspired to take this up from this RFC and @eternaleye's comment, and I hope whatever proposal this turns into is equally applicable to Rust / fleshing out the details of this RFC too!

@jonas-schievink jonas-schievink added the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Nov 26, 2019
@KodrAus KodrAus added the Libs-Tracked Libs issues that are tracked on the team's project board. label Jul 31, 2020
@joshtriplett joshtriplett added S-tracking-unimplemented Status: The feature has not been implemented. E-help-wanted Call for participation: Help is requested to fix this issue. labels Jan 26, 2022
@davidbarsky
Copy link
Contributor

Notes from lang team triage: the consensus is that the RFC looks reasonably accurate, but the design concerns not yet known. If there are design issues, the Lang Team expects that the implementor(s) would discover said design issues during implementation.

Additionally, this feature is very much desired by various teams. For instance, the standard library's expansion to platform-specific areas is semi-blocked on this implementation.

@Ericson2314
Copy link
Contributor

Ericson2314 commented Jan 26, 2022

On the E-help-wanted front, it would be great to get some academic involvement with this. Ideally we could have a library that rustc and cargo can use, because rust-lang/cargo#1197 has a very virtuous interaction with this:

  • Features should be able to depend on (aspects of) targets (e.g. io_uring backends on linux)
  • Targets should be able to depend on features (need to choose one of select, epoll, or io_uring for linux)
  • Information from Cargo on this stuff needs to feed back into checking the source code, basically for additional target_os = ... axioms.

I feel like there should be some good papers in here :) Even if the core mathematical techniques are not new, there is good empirical work on how the ecosystem would use this stuff, prevalance of platform specific code, ec.

@joshtriplett joshtriplett removed the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 15, 2023
@joshtriplett joshtriplett added the I-lang-nominated Nominated for discussion during a lang team meeting. label May 15, 2023
@joshtriplett
Copy link
Member

It seems like the current consensus among @rust-lang/lang is that this isn't the approach we want to go after all, and we'd like something type-based rather than lint-based. For instance, something based on the various "capabilities" proposals for global impls of a Trait, together with where clauses.

@rfcbot close

@rfcbot
Copy link

rfcbot commented May 15, 2023

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

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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. labels May 15, 2023
@ehuss
Copy link
Contributor

ehuss commented May 15, 2023

@joshtriplett Is there any sort of writeup that broadly explains how a type-based solution would work? I understand there are some concerns about this RFC as-is, but I haven't seen them clearly articulated.

I probably dislike conditional compilation more than most, but there are situations where I have a hard time seeing how it can be avoided, and it's hard for me to see how a type-based solution could come close to all the use cases and situations that cfg covers. It's hard to imagine that everyone will stop using cfg, so it's not clear to me how something not based on cfg would be able to answer questions like "what is the compatibility of this crate". There are perhaps other routes, such as rust-lang/cargo#6179 allowing crate authors to declare what they support, but that seems like it would be quite challenging to get adoption.

Overall I like the idea of this RFC, as it would provide a mechanism to inform someone what their code might be incompatible with. I can imagine there are some problems (like cfg doesn't cover all cases, 3 portability levels might not be the right categorization, etc.), but I'm curious what makes it fundamentally undesired.

@nikomatsakis
Copy link
Contributor

@rfcbot reviewed -- I agree with the where-clause based approach

@nikomatsakis
Copy link
Contributor

@rustbot labels -I-lang-nominated

@rustbot rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label May 16, 2023
@Ericson2314
Copy link
Contributor

Ericson2314 commented May 16, 2023

IMO type-based vs lint-based is perhaps not the distinction it sounds like it is. I imagine this would use the same logic programming machinery under-girding the trait system regardless.

The question rather of phase separation. A cfg-like system can be delay/interleaves (symbolic execution of it, basically), or it can be done eagerly. And by choosing a "model" over which do the evaluation (symbolic execution as conventionally understood would be, using the initial model) one can pick very intermediate options in between the two.

On one extremely we full where-clause, and get rid of cfg entirely, we have great compositionality and error checking, but you need all the code the all the time (think of optional deps for optional platforms). This is probably annoying especially when upstream code is more portable than downstream code.

On the other extreme is today's cfg, which only does a specific combination (single point model), for nice pruning unneeded stuff but terrible error checking.

I would like the full spectrum of options, and I would not like something that awkwardly overlaps with cfg such that people are not sure which one to use.


tl;dr new syntax greenfield system 👎 , implementing existing cfg sharing code with the trait system 👍 .

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jun 13, 2023
@rfcbot
Copy link

rfcbot commented Jun 13, 2023

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

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jun 23, 2023
@rfcbot
Copy link

rfcbot commented Jun 23, 2023

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.

@tmandry
Copy link
Member

tmandry commented Jun 28, 2023

I have not checked my box; I agree with wanting a sketch of a solution that covers the use cases of the RFC before closing.

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jun 29, 2023
@shlevy
Copy link
Contributor

shlevy commented Feb 5, 2024

@joshtriplett wrote:

It seems like the current consensus among @rust-lang/lang is that this isn't the approach we want to go after all, and we'd like something type-based rather than lint-based. For instance, something based on the various "capabilities" proposals for global impls of a Trait, together with where clauses.

Is there a link to these proposals/an elaboration of this approach?

@m-ou-se
Copy link
Member

m-ou-se commented Apr 15, 2024

The idea that I brought up several times in meetings (online and in person) but never really wrote down is basically to use where clauses for this. My belief is that #[cfg] is a terribe tool in many ways. It results in weird parallel worlds where items or entire trait implementations disappear or appear depending on the context, or even resolve to completely different items, making things very hard for clear diagnostics and good documentation.

Rust already has a much better designed mechanism for specifying conditions/bounds on items, including the machinism for then assuming those conditions are met within that item: where clauses.

Within a fn f<T>(x: T) item, you are not allowed to call x.clone(), because while it might be perfectly true that the x you're actually using can be cloned, the compiler forces you to support all types. If you add where T: Clone, you specify that you only support Clone types, so then it will let you call x.clone().

This is nearly exactly the same as what we need for platform specific items. Here's the same paragraph as the previous one, with only a few words changed:

Within your Rust code, you are not allowed to call File::read_at, because while it might be perfectly true that the platform you're actually using can do this, the compiler forces you to support all platforms. If you add where Platform: Unix, you specify that you only support unix platforms, so then it will let you call File::read_at.

So, imagine if we had something like where Platform: Unix (or even things like where Platform: UsizeIs64Bit or where Platform: HasAtomics<64>) and a way to add such a where clause to an entire crate. I think then we get pretty much exactly the behaviour we're looking for, without #[cfg], with much better potential for good documentation, clear diagnostics, and it'd fit cleanly into the rest of the language.

This would work not just for functions/methods, but also for trait impls such as impl From<u64> for usize; basically anything that supports where clauses (which might then include crates or perhaps even modules).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. E-help-wanted Call for participation: Help is requested to fix this issue. finished-final-comment-period The final comment period is finished for this PR / Issue. Libs-Tracked Libs issues that are tracked on the team's project board. S-tracking-unimplemented Status: The feature has not been implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests