​​Rust Portability WG
​​Kickoff meeting
  • ​​2018-02-22 at 1pm Pacific

​​Agenda

  • ​​Overview of pre-set goals
  • ​​Discussion and triage of goals
  • ​​Possibly: some discussion of solutions
  • ​​WG logistics

​​Possible goals

  • ​​Making it easier to port std to other targets in tree 
  • ​​Improving factoring of std
  • ​​Allowing “partial ports” to eliminate the “all-or-nothing” problem
  • ​​Making it easier to create out-of-tree targets (e.g. Rust SGX)
  • ​​Making xargo first class
  • ​​In the limit: make std fully “pluggable”, so that xargo isn’t even needed
  • ​​Difficulty: how does this interact with platform capabilities?
  • ​​Systematizing our treatment of portability
  • ​​Implementing the portability lint
  • ​​EarlyLintPass::check_attribute called too late (after stripping out unconfigured cfgs)
  • ​​Capability-based cfg flags
  • ​​Flattening the facade
  • ​​Systematizing our treatment of “global resources”
  • ​​e.g. the global allocator
  • ​​e.g. panic behavior
  • ​​could be a way to allow for greater pluggability of std
  • ​​This also applies outside of std — like logging, or event loops, or …
  • ​​Mocking out std (platform-less) for testing etc
​​
​​Some general issues/questions:
  • ​​How much is std-specific vs usable by anyone
  • ​​Some of this work can help make std maintenance and contribution easier
  • ​​Contrast to “mainstream” portability vs “niche” portability
  • ​​Can Cargo features be target-specific

​​Roster for WG/std refactoring

  • ​​bossmc - andy.m.caldwell@googlemail.com
  • ​​restricted time in short term
  • ​​mainly interested in mocking std and in-tree ports (musl target in particular weirdly)
  • ​​jethrogb
  • ​​Tom Phinney (mainly interested in embedded); tom.phinney@cox.net
  • ​​WindowsBunny retep998@gmail.com
  • ​​mainly interested in Windows specifics
  • ​​in favor of turning extension traits into inherent methods with a portability lint
  • ​​in favor of getting rid of core vs std distinction
  • ​​in favor of adding an alternative to cargo features where downstream consumers can learn what is enabled and adjust themselves accordingly, rather than demanding some feature be enabled and forcing upstream dependencies to be built accordingly
  • ​​interested in windows targets beyond desktop applications, such as drivers (both usermode and kernelmode), windows store apps, and windows nano server
  • ​​Jiri Zarevucky (@le-jzr, subject to constraints)
  • ​​mainly interested in toy/fringe use cases (mainstream has enough stakeholders as is)