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

Expose all OS-specific modules in libstd doc. #43348

Merged
merged 4 commits into from Aug 13, 2017

Conversation

Projects
None yet
@kennytm
Member

kennytm commented Jul 20, 2017

  1. Uses the special --cfg dox configuration passed by rustbuild when running rustdoc. Changes the #[cfg(platform)] into #[cfg(any(dox, platform))] so that platform-specific API are visible to rustdoc.

  2. Since platform-specific implementations often won't compile correctly on other platforms, rustdoc is changed to apply everybody_loops to the functions during documentation and doc-test harness.

  3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute #[doc(cfg(...))] is introduced to serve the above purposed.

Fixes #24658 (Does not fully implement #1998).

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jul 20, 2017

Collaborator

r? @alexcrichton

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

Collaborator

rust-highfive commented Jul 20, 2017

r? @alexcrichton

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

@carols10cents

This comment has been minimized.

Show comment
Hide comment
@carols10cents

carols10cents Jul 24, 2017

Member

friendly ping for review @alexcrichton! also pinging you on irc!

Member

carols10cents commented Jul 24, 2017

friendly ping for review @alexcrichton! also pinging you on irc!

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 26, 2017

Member

Ah sorry for the delay, but thanks for the PR @kennytm! This has defnitely long since been one of the major issues with the documentation of the standard library, and it's exciting to see movement towards fixing it!

This is a pretty big PR though is sort of difficult to review, and it's unclear to me at least how easy it'll be to maintain this into the future. I wonder if we could pursue a slightly smaller implementation in the meantime which may have practically the same impact? It looks like a lot of the complication here comes from handling the MetadataExt trait in various modules, but since those are all deprecated anyway I wonder if we could avoid them?

The "biggies" to handle here I think are std::os::{unix, windows} and I think the support needed for the may be a bit smaller? What do you think?

One other worry I'd have is that I think we'll want to do an audit of the documentation to ensure that everything is clearly documented as either Unix or Windows specific. Otherwise it may be confusing to see those windows methods in the Unix docs!

Also cc @rust-lang/libs, others may be interested in this as well!

Member

alexcrichton commented Jul 26, 2017

Ah sorry for the delay, but thanks for the PR @kennytm! This has defnitely long since been one of the major issues with the documentation of the standard library, and it's exciting to see movement towards fixing it!

This is a pretty big PR though is sort of difficult to review, and it's unclear to me at least how easy it'll be to maintain this into the future. I wonder if we could pursue a slightly smaller implementation in the meantime which may have practically the same impact? It looks like a lot of the complication here comes from handling the MetadataExt trait in various modules, but since those are all deprecated anyway I wonder if we could avoid them?

The "biggies" to handle here I think are std::os::{unix, windows} and I think the support needed for the may be a bit smaller? What do you think?

One other worry I'd have is that I think we'll want to do an audit of the documentation to ensure that everything is clearly documented as either Unix or Windows specific. Otherwise it may be confusing to see those windows methods in the Unix docs!

Also cc @rust-lang/libs, others may be interested in this as well!

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Jul 28, 2017

Member

@alexcrichton Thanks for the comments :)

I've reverted most of the MetadataExt change. Now only std::os::linux is exposed, just like before. But I don't think MetadataExt the trait is deprecated; only the as_raw_stat() method is deprecated.

(Additionally, the documented_os_specific_impl! macro is downsized a lot thanks to the new stage0.)

This PR only labels OsStrExt/OsStringExt with the "Windows only" and "Unix only" labels, since I believe these will confuse most people. There could be a special badge for these non-portable function, like the stability badge.

Ideally this should be handled by rustdoc by checking the #[cfg], perhaps after #41619 (rust-lang/rfcs#1868 "a portability lint") is implemented. The RFC would also render this PR and the whole std::os module obsolete.

(↓ Not implemented in this PR)

Member

kennytm commented Jul 28, 2017

@alexcrichton Thanks for the comments :)

I've reverted most of the MetadataExt change. Now only std::os::linux is exposed, just like before. But I don't think MetadataExt the trait is deprecated; only the as_raw_stat() method is deprecated.

(Additionally, the documented_os_specific_impl! macro is downsized a lot thanks to the new stage0.)

This PR only labels OsStrExt/OsStringExt with the "Windows only" and "Unix only" labels, since I believe these will confuse most people. There could be a special badge for these non-portable function, like the stability badge.

Ideally this should be handled by rustdoc by checking the #[cfg], perhaps after #41619 (rust-lang/rfcs#1868 "a portability lint") is implemented. The RFC would also render this PR and the whole std::os module obsolete.

(↓ Not implemented in this PR)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 31, 2017

Member

Oh right yes, MetadataExt is indeed not deprecated!

Reading over this again though I'm still pretty wary personally. This seems very meticulously crafted in the sense that it's going to be pretty difficult to maintain over time. For example I could see that perhaps impls are added which involve adding more and more cases to the documented_os_specific_impl macro (or other related macros). It would be great to solve this problem though!

I wonder if perhaps we pursue solutions in rustdoc other than the standard library? For example there's no real need for rustdoc to actually typecheck these function bodies. Could rustdoc unconditionally always replace all function bodies with loop {}? That would remove the need for the macro I think, right?

I think we may want to also pursue a solution in rustdoc for the code examples here. For example we could have something like unix in the three backticks (or windows) to indicate that the example only runs on one platform maybe? Or better yet we could have something like #[doc(cfg(unix))] which could be an unstable attribute for now but indicate that rustdoc should (a) only compile examples on that platform and (b) warn in the docs that the function is unix-only in a uniform fashion.

Overall I'm just wondering if we could reduce the maintenance burden on the standard library as we add more impls/examples here over time!

Member

alexcrichton commented Jul 31, 2017

Oh right yes, MetadataExt is indeed not deprecated!

Reading over this again though I'm still pretty wary personally. This seems very meticulously crafted in the sense that it's going to be pretty difficult to maintain over time. For example I could see that perhaps impls are added which involve adding more and more cases to the documented_os_specific_impl macro (or other related macros). It would be great to solve this problem though!

I wonder if perhaps we pursue solutions in rustdoc other than the standard library? For example there's no real need for rustdoc to actually typecheck these function bodies. Could rustdoc unconditionally always replace all function bodies with loop {}? That would remove the need for the macro I think, right?

I think we may want to also pursue a solution in rustdoc for the code examples here. For example we could have something like unix in the three backticks (or windows) to indicate that the example only runs on one platform maybe? Or better yet we could have something like #[doc(cfg(unix))] which could be an unstable attribute for now but indicate that rustdoc should (a) only compile examples on that platform and (b) warn in the docs that the function is unix-only in a uniform fashion.

Overall I'm just wondering if we could reduce the maintenance burden on the standard library as we add more impls/examples here over time!

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Jul 31, 2017

Member

@alexcrichton Sounds good to me! That could get rid of documented_os_specific_impl, but I think cfg(dox) still have the stay, right?

(cc @GuillaumeGomez @steveklabnik about the potential rustdoc changes)

Member

kennytm commented Jul 31, 2017

@alexcrichton Sounds good to me! That could get rid of documented_os_specific_impl, but I think cfg(dox) still have the stay, right?

(cc @GuillaumeGomez @steveklabnik about the potential rustdoc changes)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 31, 2017

Member

Yeah we'll definitely still need #[cfg(dox)] in one way or another, I'm just hoping that we can reduce the amount of #[cfg(dox)] to O(1) basically in terms of some constant overhead but not needing annotation per-function (ideally at least)

Member

alexcrichton commented Jul 31, 2017

Yeah we'll definitely still need #[cfg(dox)] in one way or another, I'm just hoping that we can reduce the amount of #[cfg(dox)] to O(1) basically in terms of some constant overhead but not needing annotation per-function (ideally at least)

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Jul 31, 2017

Member

Wo, that's quite the improvement! Consider I'm all 👍

Member

GuillaumeGomez commented Jul 31, 2017

Wo, that's quite the improvement! Consider I'm all 👍

@kennytm kennytm changed the title from Expose all OS-specific modules in libstd doc. to [WIP] Expose all OS-specific modules in libstd doc. Aug 4, 2017

@kennytm kennytm changed the title from [WIP] Expose all OS-specific modules in libstd doc. to Expose all OS-specific modules in libstd doc. Aug 5, 2017

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Aug 5, 2017

Member

@alexcrichton Updated to include everybody_loops (in 622248a) and #[doc(cfg(...))] (in 3dea51f).

I did not feature-gate doc(cfg(...)) since all other doc() attributes like doc(no_default_passes) are not.

Current output. cc @GuillaumeGomez some CSS changed.


1-fs8


2-fs8


Fullpage screenshot of `Metadata` structure

3-fullpage-fs8

Member

kennytm commented Aug 5, 2017

@alexcrichton Updated to include everybody_loops (in 622248a) and #[doc(cfg(...))] (in 3dea51f).

I did not feature-gate doc(cfg(...)) since all other doc() attributes like doc(no_default_passes) are not.

Current output. cc @GuillaumeGomez some CSS changed.


1-fs8


2-fs8


Fullpage screenshot of `Metadata` structure

3-fullpage-fs8

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Aug 5, 2017

Member

Seems good to me (for the CSS part).

Member

GuillaumeGomez commented Aug 5, 2017

Seems good to me (for the CSS part).

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Aug 8, 2017

Contributor

@alexcrichton - are you looking at reviewing this? Friendly ping to make sure this isn't getting lost.

Contributor

arielb1 commented Aug 8, 2017

@alexcrichton - are you looking at reviewing this? Friendly ping to make sure this isn't getting lost.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 8, 2017

Member

This is awesome!

Member

aturon commented Aug 8, 2017

This is awesome!

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 9, 2017

Member

This also looks fantastic to me, thanks so much for taking on the refactoring @kennytm!

Only two thoughts now at this point:

  • Would it be easy to feature-gate the #[doc(cfg(..))] attribute for now? Just to not break code by accident if we change this in the future.
  • Could a few rustdoc tests be added for #[doc(cfg(..))] and what it renders? Namely the inheritance logic and such.
Member

alexcrichton commented Aug 9, 2017

This also looks fantastic to me, thanks so much for taking on the refactoring @kennytm!

Only two thoughts now at this point:

  • Would it be easy to feature-gate the #[doc(cfg(..))] attribute for now? Just to not break code by accident if we change this in the future.
  • Could a few rustdoc tests be added for #[doc(cfg(..))] and what it renders? Namely the inheritance logic and such.
@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Aug 9, 2017

Member

I went ahead and checked out this PR to render an example std doc bundle with it: https://tonberry.quietmisdreavus.net/std-43348/std/os/index.html (This is rendered on a Linux server, in case that's useful information.)

Member

QuietMisdreavus commented Aug 9, 2017

I went ahead and checked out this PR to render an example std doc bundle with it: https://tonberry.quietmisdreavus.net/std-43348/std/os/index.html (This is rendered on a Linux server, in case that's useful information.)

@kennytm kennytm referenced this pull request Aug 10, 2017

Open

Tracking issue for `#[doc(cfg(...))]` #43781

1 of 3 tasks complete
@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Aug 10, 2017

Member

@alexcrichton Done :). Feature gate tracked in #43781.

Member

kennytm commented Aug 10, 2017

@alexcrichton Done :). Feature gate tracked in #43781.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 10, 2017

Contributor

☔️ The latest upstream changes (presumably #43730) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Aug 10, 2017

☔️ The latest upstream changes (presumably #43730) made this pull request unmergeable. Please resolve the merge conflicts.

kennytm added some commits Jul 19, 2017

Strip out function implementation when documenting.
This prevents compilation failure we want to document a platform-specific
module. Every function is replaced by `loop {}` using the same construct
as `--unpretty everybody_loops`.

Note also a workaround to #43636 is included: `const fn` will retain their
bodies, since the standard library has quite a number of them.
Implemented #[doc(cfg(...))].
This attribute has two effects:

1. Items with this attribute and their children will have the "This is
   supported on **** only" message attached in the documentation.

2. The items' doc tests will be skipped if the configuration does not
   match.
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 10, 2017

Member

@bors: r+

Looks great to me, thanks so much again @kennytm!

Member

alexcrichton commented Aug 10, 2017

@bors: r+

Looks great to me, thanks so much again @kennytm!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 10, 2017

Contributor

📌 Commit b4114eb has been approved by alexcrichton

Contributor

bors commented Aug 10, 2017

📌 Commit b4114eb has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 10, 2017

Contributor

⌛️ Testing commit b4114eb with merge 8939616...

Contributor

bors commented Aug 10, 2017

⌛️ Testing commit b4114eb with merge 8939616...

bors added a commit that referenced this pull request Aug 10, 2017

Auto merge of #43348 - kennytm:fix-24658-doc-every-platform, r=alexcr…
…ichton

Expose all OS-specific modules in libstd doc.

1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.

2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.

3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.

Fixes #24658 (Does _not_ fully implement #1998).
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 10, 2017

Contributor

💔 Test failed - status-travis

Contributor

bors commented Aug 10, 2017

💔 Test failed - status-travis

@aidanhs

This comment has been minimized.

Show comment
Hide comment
@aidanhs

aidanhs Aug 10, 2017

Member
[00:40:47] error[E0412]: cannot find type `WSADATA` in this scope
[00:40:47]   --> /checkout/src/libstd/sys/windows/c.rs:71:27
[00:40:47]    |
[00:40:47] 71 | pub type LPWSADATA = *mut WSADATA;
[00:40:47]    |                           ^^^^^^^ did you mean `LPWSADATA`?
[00:40:47] 
[00:40:47] error[E0412]: cannot find type `CONTEXT` in this scope
[00:40:47]    --> /checkout/src/libstd/sys/windows/c.rs:493:29
[00:40:47]     |
[00:40:47] 493 |     pub ContextRecord: *mut CONTEXT,
[00:40:47]     |                             ^^^^^^^ not found in this scope
[00:40:47] 
[00:40:47] error[E0412]: cannot find type `CONTEXT` in this scope
[00:40:47]     --> /checkout/src/libstd/sys/windows/c.rs:1080:40
[00:40:47]      |
[00:40:47] 1080 |     pub fn RtlCaptureContext(ctx: *mut CONTEXT);
[00:40:47]      |                                        ^^^^^^^ not found in this scope

Seems legit

Member

aidanhs commented Aug 10, 2017

[00:40:47] error[E0412]: cannot find type `WSADATA` in this scope
[00:40:47]   --> /checkout/src/libstd/sys/windows/c.rs:71:27
[00:40:47]    |
[00:40:47] 71 | pub type LPWSADATA = *mut WSADATA;
[00:40:47]    |                           ^^^^^^^ did you mean `LPWSADATA`?
[00:40:47] 
[00:40:47] error[E0412]: cannot find type `CONTEXT` in this scope
[00:40:47]    --> /checkout/src/libstd/sys/windows/c.rs:493:29
[00:40:47]     |
[00:40:47] 493 |     pub ContextRecord: *mut CONTEXT,
[00:40:47]     |                             ^^^^^^^ not found in this scope
[00:40:47] 
[00:40:47] error[E0412]: cannot find type `CONTEXT` in this scope
[00:40:47]     --> /checkout/src/libstd/sys/windows/c.rs:1080:40
[00:40:47]      |
[00:40:47] 1080 |     pub fn RtlCaptureContext(ctx: *mut CONTEXT);
[00:40:47]      |                                        ^^^^^^^ not found in this scope

Seems legit

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 11, 2017

Contributor

📌 Commit b1b350e has been approved by alexcrichton

Contributor

bors commented Aug 11, 2017

📌 Commit b1b350e has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 11, 2017

Contributor

⌛️ Testing commit b1b350e with merge 3616c04...

Contributor

bors commented Aug 11, 2017

⌛️ Testing commit b1b350e with merge 3616c04...

bors added a commit that referenced this pull request Aug 11, 2017

Auto merge of #43348 - kennytm:fix-24658-doc-every-platform, r=alexcr…
…ichton

Expose all OS-specific modules in libstd doc.

1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.

2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.

3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.

Fixes #24658 (Does _not_ fully implement #1998).
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 11, 2017

Contributor

💔 Test failed - status-appveyor

Contributor

bors commented Aug 11, 2017

💔 Test failed - status-appveyor

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Aug 11, 2017

Member

Legit, libc::sockaddr_un and libc::socklen_t undefined on Windows.

Member

kennytm commented Aug 11, 2017

Legit, libc::sockaddr_un and libc::socklen_t undefined on Windows.

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Aug 11, 2017

Member

Fixed it by creating fake definitions of these on non-Unix. @alexcrichton

#[cfg(not(unix))]
mod libc {
    pub use libc::c_int;
    pub type socklen_t = u32;
    pub struct sockaddr;
    #[derive(Clone)]
    pub struct sockaddr_un;
}

These don't affect the official documentation since they are only used in implementation detail.

Member

kennytm commented Aug 11, 2017

Fixed it by creating fake definitions of these on non-Unix. @alexcrichton

#[cfg(not(unix))]
mod libc {
    pub use libc::c_int;
    pub type socklen_t = u32;
    pub struct sockaddr;
    #[derive(Clone)]
    pub struct sockaddr_un;
}

These don't affect the official documentation since they are only used in implementation detail.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

alexcrichton commented Aug 12, 2017

@bors: r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 12, 2017

Contributor

📌 Commit 3093bb8 has been approved by alexcrichton

Contributor

bors commented Aug 12, 2017

📌 Commit 3093bb8 has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 13, 2017

Contributor

⌛️ Testing commit 3093bb8 with merge 0ed03e5...

Contributor

bors commented Aug 13, 2017

⌛️ Testing commit 3093bb8 with merge 0ed03e5...

bors added a commit that referenced this pull request Aug 13, 2017

Auto merge of #43348 - kennytm:fix-24658-doc-every-platform, r=alexcr…
…ichton

Expose all OS-specific modules in libstd doc.

1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.

2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.

3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.

Fixes #24658 (Does _not_ fully implement #1998).
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 13, 2017

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 0ed03e5 to master...

Contributor

bors commented Aug 13, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 0ed03e5 to master...

@bors bors merged commit 3093bb8 into rust-lang:master Aug 13, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@kennytm kennytm deleted the kennytm:fix-24658-doc-every-platform branch Aug 13, 2017

@nrc nrc referenced this pull request Aug 16, 2017

Closed

Tools news #25

@oli-obk oli-obk referenced this pull request Sep 6, 2017

Open

Meta issue for FIXMEs that reference closed issues #44366

24 of 153 tasks complete

bors added a commit that referenced this pull request Sep 19, 2017

Auto merge of #44026 - QuietMisdreavus:trimmed-std, r=steveklabnik
hide internal types/traits from std docs via new #[doc(masked)] attribute

Fixes #43701 (hopefully for good this time)

This PR introduces a new parameter to the `#[doc]` attribute that rustdoc looks for on `extern crate` statements. When it sees `#[doc(masked)]` on such a statement, it hides traits and types from that crate from appearing in either the "Trait Implementations" section of many type pages, or the "Implementors" section of trait pages. This is then applied to the `libc`/`rand`/`compiler_builtins` imports in libstd to prevent those crates from creating broken links in the std docs.

Like in #43348, this also introduces a feature gate, `doc_masked`, that controls the use of this parameter.

To view the std docs generated with this change, head to https://tonberry.quietmisdreavus.net/std-43701/std/index.html.

@QuietMisdreavus QuietMisdreavus referenced this pull request Sep 20, 2017

Open

API Docs: os #29367

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Nov 3, 2017

Update to 1.21.0
Changelog:
Version 1.21.0 (2017-10-12)
==========================

Language
--------
- [You can now use static references for literals.][43838]
  Example:
  ```rust
  fn main() {
      let x: &'static u32 = &0;
  }
  ```
- [Relaxed path syntax. Optional `::` before `<` is now allowed in all contexts.][43540]
  Example:
  ```rust
  my_macro!(Vec<i32>::new); // Always worked
  my_macro!(Vec::<i32>::new); // Now works
  ```

Compiler
--------
- [Upgraded jemalloc to 4.5.0][43911]
- [Enabled unwinding panics on Redox][43917]
- [Now runs LLVM in parallel during translation phase.][43506]
  This should reduce peak memory usage.

Libraries
---------
- [Generate builtin impls for `Clone` for all arrays and tuples that
  are `T: Clone`][43690]
- [`Stdin`, `Stdout`, and `Stderr` now implement `AsRawFd`.][43459]
- [`Rc` and `Arc` now implement `From<&[T]> where T: Clone`, `From<str>`,
  `From<String>`, `From<Box<T>> where T: ?Sized`, and `From<Vec<T>>`.][42565]

Stabilized APIs
---------------

[`std::mem::discriminant`]

Cargo
-----
- [You can now call `cargo install` with multiple package names][cargo/4216]
- [Cargo commands inside a virtual workspace will now implicitly
  pass `--all`][cargo/4335]
- [Added a `[patch]` section to `Cargo.toml` to handle
  prepublication dependencies][cargo/4123] [RFC 1969]
- [`include` & `exclude` fields in `Cargo.toml` now accept gitignore
  like patterns][cargo/4270]
- [Added the `--all-targets` option][cargo/4400]
- [Using required dependencies as a feature is now deprecated and emits
  a warning][cargo/4364]


Misc
----
- [Cargo docs are moving][43916]
  to [doc.rust-lang.org/cargo](https://doc.rust-lang.org/cargo)
- [The rustdoc book is now available][43863]
  at [doc.rust-lang.org/rustdoc](https://doc.rust-lang.org/rustdoc)
- [Added a preview of RLS has been made available through rustup][44204]
  Install with `rustup component add rls-preview`
- [`std::os` documentation for Unix, Linux, and Windows now appears on doc.rust-lang.org][43348]
  Previously only showed `std::os::unix`.

Compatibility Notes
-------------------
- [Changes in method matching against higher-ranked types][43880] This may cause
  breakage in subtyping corner cases. [A more in-depth explanation is available.][info/43880]
- [rustc's JSON error output's byte position start at top of file.][42973]
  Was previously relative to the rustc's internal `CodeMap` struct which
  required the unstable library `libsyntax` to correctly use.
- [`unused_results` lint no longer ignores booleans][43728]

[42565]: rust-lang/rust#42565
[42973]: rust-lang/rust#42973
[43348]: rust-lang/rust#43348
[43459]: rust-lang/rust#43459
[43506]: rust-lang/rust#43506
[43540]: rust-lang/rust#43540
[43690]: rust-lang/rust#43690
[43728]: rust-lang/rust#43728
[43838]: rust-lang/rust#43838
[43863]: rust-lang/rust#43863
[43880]: rust-lang/rust#43880
[43911]: rust-lang/rust#43911
[43916]: rust-lang/rust#43916
[43917]: rust-lang/rust#43917
[44204]: rust-lang/rust#44204
[cargo/4123]: rust-lang/cargo#4123
[cargo/4216]: rust-lang/cargo#4216
[cargo/4270]: rust-lang/cargo#4270
[cargo/4335]: rust-lang/cargo#4335
[cargo/4364]: rust-lang/cargo#4364
[cargo/4400]: rust-lang/cargo#4400
[RFC 1969]: rust-lang/rfcs#1969
[info/43880]: rust-lang/rust#44224 (comment)
[`std::mem::discriminant`]: https://doc.rust-lang.org/std/mem/fn.discriminant.html
@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Aug 1, 2018

Member

I just want to say I'm astounded that everybody_loops (#19964) got (re)purposed for this task!

Member

pnkfelix commented Aug 1, 2018

I just want to say I'm astounded that everybody_loops (#19964) got (re)purposed for this task!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment