Restrict where in the tree platform-specific cfgs may be mentioned#36807

brson · 2016-09-28T19:01:23Z

With the ports of Rust never ending, it's important that we keep things tidy. The main thing this PR does is introduce a new "pal" (platform abstraction layer) tidy check that limits where platform-specific CFGs may appear.

This is intended to maintain existing standards of code organization
in hopes that the standard library will continue to be refactored to
isolate platform-specific bits, making porting easier; where "standard
library" roughly means "all the dependencies of the std and test
crates".

This generally means placing restrictions on where cfg(unix),
cfg(windows), cfg(target_os) and cfg(target_env) may appear,
the basic objective being to isolate platform-specific code to the
platform-specific std::sys modules, and to the allocation,
unwinding, and libc crates.

Following are the basic rules, though there are currently
exceptions:

core may not have platform-specific code
liballoc_system may have platform-specific code
liballoc_jemalloc may have platform-specific code
libpanic_abort may have platform-specific code
libpanic_unwind may have platform-specific code
other crates in the std facade may not
std may have platform-specific code in the following places
- sys/unix/
- sys/windows/
- os/

There are plenty of exceptions today though, noted in the whitelist.

The end-state, IMO, is for the standard library to be portable by porting only std::sys (possibly extracted to its own crate), an allocator crate, an unwinder crate, and possibly a libc crate (if std depends on it); but that outcome is far off and independent of the utility of enforcing where such code lives today.

cc @rust-lang/libs

rust-highfive · 2016-09-28T19:01:29Z

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2016-09-29T00:05:26Z

Looks great to me!

alexcrichton · 2016-09-29T00:01:54Z

src/libstd/sys/windows/env.rs

This can be removed I think

brson · 2016-09-29T00:37:06Z

Updated.

brson · 2016-09-29T22:14:08Z

r? @alexcrichton

brson · 2016-09-29T22:14:46Z

I did some more refactoring, moving the argument handling around. That'll surely bounce a few times on misc platforms...

alexcrichton · 2016-09-29T22:19:40Z

@bors: r+

bors · 2016-09-29T22:19:41Z

📌 Commit 2086608 has been approved by alexcrichton

brson · 2016-09-29T22:33:51Z

@bors r=alexcrichton

bors · 2016-09-29T22:33:52Z

📌 Commit 54440be has been approved by alexcrichton

brson · 2016-09-30T01:12:06Z

@bors r=alexcrichton

bors · 2016-09-30T01:12:06Z

📌 Commit 5cf31ba has been approved by alexcrichton

brson · 2016-09-30T01:31:54Z

@bors r=alexcrichton

bors · 2016-09-30T01:31:55Z

📌 Commit 1472c45 has been approved by alexcrichton

bors · 2016-09-30T06:50:36Z

⌛ Testing commit 1472c45 with merge dbcc5b1...

bors · 2016-09-30T07:10:10Z

💔 Test failed - auto-win-gnu-32-opt-rustbuild

brson · 2016-09-30T15:11:20Z

@bors r=alexcrichton

bors · 2016-09-30T15:11:21Z

📌 Commit ba9e75e has been approved by alexcrichton

brson · 2016-09-30T19:28:20Z

@bors r=alexcrichton

brson · 2016-10-01T20:13:43Z

@bors r=alexcrichton

bors · 2016-10-01T20:13:44Z

📌 Commit 1a30e0f has been approved by alexcrichton

bors · 2016-10-01T20:49:20Z

⌛ Testing commit 1a30e0f with merge bdded68...

bors · 2016-10-01T21:53:03Z

💔 Test failed - auto-mac-cross-ios-opt

brson · 2016-10-01T23:29:25Z

@bors r=alexcrichton

bors · 2016-10-01T23:29:26Z

📌 Commit 405c010 has been approved by alexcrichton

bors · 2016-10-02T01:11:36Z

⌛ Testing commit 405c010 with merge d97a08e...

Restrict where in the tree platform-specific cfgs may be mentioned With the ports of Rust never ending, it's important that we keep things tidy. The main thing this PR does is introduce a new "pal" (platform abstraction layer) tidy check that limits where platform-specific CFGs may appear. This is intended to maintain existing standards of code organization in hopes that the standard library will continue to be refactored to isolate platform-specific bits, making porting easier; where "standard library" roughly means "all the dependencies of the std and test crates". This generally means placing restrictions on where `cfg(unix)`, `cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear, the basic objective being to isolate platform-specific code to the platform-specific `std::sys` modules, and to the allocation, unwinding, and libc crates. Following are the basic rules, though there are currently exceptions: - core may not have platform-specific code - liballoc_system may have platform-specific code - liballoc_jemalloc may have platform-specific code - libpanic_abort may have platform-specific code - libpanic_unwind may have platform-specific code - other crates in the std facade may not - std may have platform-specific code in the following places - sys/unix/ - sys/windows/ - os/ There are plenty of exceptions today though, noted in the whitelist. The end-state, IMO, is for the standard library to be portable by porting only `std::sys` (possibly extracted to its own crate), an allocator crate, an unwinder crate, and possibly a libc crate (if std depends on it); but that outcome is far off and independent of the utility of enforcing where such code lives today. cc @rust-lang/libs

bors · 2016-10-02T03:34:34Z

💔 Test failed - auto-win-msvc-32-opt

brson · 2016-10-02T18:03:44Z

@bors r=alexcrichton

bors · 2016-10-02T18:03:45Z

📌 Commit 61afff3 has been approved by alexcrichton

bors · 2016-10-02T19:00:35Z

⌛ Testing commit 61afff3 with merge f3add2e...

bors · 2016-10-02T21:13:26Z

💔 Test failed - auto-linux-32-opt

This is intended to maintain existing standards of code organization in hopes that the standard library will continue to be refactored to isolate platform-specific bits, making porting easier; where "standard library" roughly means "all the dependencies of the std and test crates". This generally means placing restrictions on where `cfg(unix)`, `cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear, the basic objective being to isolate platform-specific code to the platform-specific `std::sys` modules, and to the allocation, unwinding, and libc crates. Following are the basic rules, though there are currently exceptions: - core may not have platform-specific code - liballoc_system may have platform-specific code - liballoc_jemalloc may have platform-specific code - libpanic_abort may have platform-specific code - libpanic_unwind may have platform-specific code - other crates in the std facade may not - std may have platform-specific code in the following places - sys/unix/ - sys/windows/ - os/ There are plenty of exceptions today though, noted in the whitelist.

brson · 2016-10-02T21:54:50Z

@bors r+

bors · 2016-10-02T21:54:51Z

📌 Commit 4d76ac8 has been approved by brson

bors · 2016-10-03T00:33:35Z

⌛ Testing commit 4d76ac8 with merge 144af3e...

Restrict where in the tree platform-specific cfgs may be mentioned With the ports of Rust never ending, it's important that we keep things tidy. The main thing this PR does is introduce a new "pal" (platform abstraction layer) tidy check that limits where platform-specific CFGs may appear. This is intended to maintain existing standards of code organization in hopes that the standard library will continue to be refactored to isolate platform-specific bits, making porting easier; where "standard library" roughly means "all the dependencies of the std and test crates". This generally means placing restrictions on where `cfg(unix)`, `cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear, the basic objective being to isolate platform-specific code to the platform-specific `std::sys` modules, and to the allocation, unwinding, and libc crates. Following are the basic rules, though there are currently exceptions: - core may not have platform-specific code - liballoc_system may have platform-specific code - liballoc_jemalloc may have platform-specific code - libpanic_abort may have platform-specific code - libpanic_unwind may have platform-specific code - other crates in the std facade may not - std may have platform-specific code in the following places - sys/unix/ - sys/windows/ - os/ There are plenty of exceptions today though, noted in the whitelist. The end-state, IMO, is for the standard library to be portable by porting only `std::sys` (possibly extracted to its own crate), an allocator crate, an unwinder crate, and possibly a libc crate (if std depends on it); but that outcome is far off and independent of the utility of enforcing where such code lives today. cc @rust-lang/libs

bors · 2016-10-03T04:51:08Z

rust-highfive assigned aturon Sep 28, 2016

alexcrichton reviewed Sep 29, 2016

View reviewed changes

src/libstd/sys/windows/env.rs Outdated

Copy link
Copy Markdown

Member

alexcrichton Sep 29, 2016

Choose a reason for hiding this comment

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

This can be removed I think

brson force-pushed the pal branch from 6b8065a to c6c89f0 Compare September 29, 2016 00:36

brson force-pushed the pal branch from 4efa10f to 2086608 Compare September 29, 2016 22:12

rust-highfive assigned alexcrichton and unassigned aturon Sep 29, 2016

brson force-pushed the pal branch from 2086608 to 54440be Compare September 29, 2016 22:33

brson force-pushed the pal branch from 54440be to 5cf31ba Compare September 30, 2016 01:11

brson force-pushed the pal branch from 5cf31ba to 1472c45 Compare September 30, 2016 01:31

brson force-pushed the pal branch from 1472c45 to ba9e75e Compare September 30, 2016 15:11

brson force-pushed the pal branch from ba9e75e to 57cd2d6 Compare September 30, 2016 19:27

brson force-pushed the pal branch from b710344 to 1a30e0f Compare October 1, 2016 20:13

brson force-pushed the pal branch from 1a30e0f to 405c010 Compare October 1, 2016 23:29

brson force-pushed the pal branch from 405c010 to 61afff3 Compare October 2, 2016 18:03

brson added 2 commits October 2, 2016 14:52

Move platform-specific arg handling to sys::args

4d76ac8

brson force-pushed the pal branch from 61afff3 to 4d76ac8 Compare October 2, 2016 21:54

bors merged commit 4d76ac8 into rust-lang:master Oct 3, 2016

bors mentioned this pull request Oct 3, 2016

Fix UB in transmute #34181

Closed

Mark-Simulacrum mentioned this pull request Oct 4, 2016

Potential compile time regression in item-types checking #36947

Closed

brson mentioned this pull request Oct 17, 2016

Port libstd to "no operating system" target #37133

Closed

Uh oh!

Conversation

brson commented Sep 28, 2016

Uh oh!

rust-highfive commented Sep 28, 2016

Uh oh!

alexcrichton commented Sep 29, 2016

Uh oh!

alexcrichton Sep 29, 2016

Choose a reason for hiding this comment

Uh oh!

brson commented Sep 29, 2016

Uh oh!

brson commented Sep 29, 2016

Uh oh!

brson commented Sep 29, 2016

Uh oh!

alexcrichton commented Sep 29, 2016

Uh oh!

bors commented Sep 29, 2016

Uh oh!

brson commented Sep 29, 2016

Uh oh!

bors commented Sep 29, 2016

Uh oh!

brson commented Sep 30, 2016

Uh oh!

bors commented Sep 30, 2016

Uh oh!

brson commented Sep 30, 2016

Uh oh!

bors commented Sep 30, 2016

Uh oh!

bors commented Sep 30, 2016

Uh oh!

bors commented Sep 30, 2016

Uh oh!

brson commented Sep 30, 2016

Uh oh!

bors commented Sep 30, 2016

Uh oh!

brson commented Sep 30, 2016

Uh oh!

brson commented Oct 1, 2016

Uh oh!

bors commented Oct 1, 2016

Uh oh!

bors commented Oct 1, 2016

Uh oh!

bors commented Oct 1, 2016

Uh oh!

brson commented Oct 1, 2016

Uh oh!

bors commented Oct 1, 2016

Uh oh!

bors commented Oct 2, 2016

Uh oh!

bors commented Oct 2, 2016

Uh oh!

brson commented Oct 2, 2016

Uh oh!

bors commented Oct 2, 2016

Uh oh!

bors commented Oct 2, 2016

Uh oh!

bors commented Oct 2, 2016

Uh oh!

brson commented Oct 2, 2016

Uh oh!

bors commented Oct 2, 2016

Uh oh!

bors commented Oct 3, 2016

Uh oh!

bors commented Oct 3, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone