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

Stabilize underscore_imports #56303

Merged
merged 1 commit into from
Dec 18, 2018
Merged

Stabilize underscore_imports #56303

merged 1 commit into from
Dec 18, 2018

Conversation

petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Nov 28, 2018

Closes #48216

@petrochenkov
Copy link
Contributor Author

r? @Centril

@petrochenkov
Copy link
Contributor Author

petrochenkov commented Nov 28, 2018

Stabilization report

Feature name: #![feature(underscore_imports)]
Version target: 1.32 (2019-01-18)

Implemented in #48922 and landed 8.5 months ago.
Tracking issue is #48216.
Documentation issue is rust-lang/reference#470.
Tests for the feature can be found in src/test/ui/rfc-2166-underscore-imports.

What is being stabilized

use path as _; imports the path path and renames it into some unique identifier that can't be written explicitly.
For traits this means Trait's methods are now in scope in module/block into which use Trait as _; is placed.
For non-traits the import has no effect and is reported as unused by the unused_imports lint.

Additional effect on 2018 edition is that use my_crate::a::b as _; can refer to an extern crate my_crate and link it.
However, the import is still reported as unused in this case, unless it's of the form use my_crate as _; (add test tested in #56392).

extern crate name as _; imports the crate name and renames it into some unique identifier that can't be written explicitly.
The crate imported this way is linked, so the feature can be used for link-only crates, and the crate is not reported as unused in this case (add test tested in #56392).
If #[macro_use] is attached to such crate it works as usual and imports macros from name into prelude (add test? tested in #56392).

Some details and corner cases

Despite the name introduced with _ being unnameable explicitly, it still can be fetched by glob imports.
So, something like use super::*; reimports traits brought in scope with use Trait as _; in the parent module, and their methods become available in the child module.

Underscore imports can be public - pub use Trait as _;, this also can make sense in combination with glob imports.

Open questions

If procedural macro clones the _ token from its input, will it refer to the same unique identifier?
Right now the answer is yes, the "unique identifier" is created during parsing, so procedural macros (and declarative macros as well, if you try hard enough (add test tested in #56392)) can clone it while keeping its identity.
It's possible to implement it differently, so unique identifiers are only created during name resolution, after macro expansion.
UPDATE: Creation of gensyms is delayed until name resolution in #56392, so macros cannot clone them anymore.

Known issues

"Unique identifiers" (gensyms) are lost in crate metadata, so all _s become same after being imported from another crate.
This is a hard issue to solve, but it doesn't prevent the common use case of _ imports for importing traits, which doesn't normally assume reexporting _ imports to other crates.
UPDATE: Mostly fixed in #56392.

_ imports and other imports in general, are known to be buggy when used together with macros 2.0 (macro items or Span::def_site), but this only affects unstable code.

@petrochenkov
Copy link
Contributor Author

I'm especially interested in opinions regarding interactions with proc macros ("Open questions" in #56303 (comment)).
cc @dtolnay

Copy link
Contributor

@Centril Centril left a comment

Choose a reason for hiding this comment

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

Looks good pending tests passing and pending some of the additional tests discussed above.

@Centril Centril added T-lang Relevant to the language team, which will review and decide on the PR/issue. relnotes Marks issues that should be documented in the release notes of the next release. labels Nov 28, 2018
@Centril
Copy link
Contributor

Centril commented Nov 28, 2018

Thanks for the thoroughly detailed report <3.

I propose that we stabilize #![feature(underscore_imports)] with a version target of 1.32 (or later if necessary...) for all editions (2015 and 2018).

As for the open questions re. macros, I propose that we create unique identifiers during name resolution and after macro expansion such that (#56303 (comment)):

#[my_macro]
use path::to::Trait as _;

// expands to

use path::to::Trait1 as _;
use path::to::Trait2 as _; // the same underscore token

is not an error (same for the declarative macro case in #56303 (comment)).

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Nov 28, 2018

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), 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.

@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-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 28, 2018
@dtolnay
Copy link
Member

dtolnay commented Nov 28, 2018

To make sure I understand the procedural macro consideration: would the following be an example of the edge case you have in mind?

#[my_macro]
use path::to::Trait as _;

// expands to

use path::to::Trait1 as _;
use path::to::Trait2 as _; // the same underscore token

and these would be conflicting imports because they reuse the same gensym?

@petrochenkov
Copy link
Contributor Author

@dtolnay
Yes, exactly.

The declarative macro equivalent is

#![feature(underscore_imports)]
#![allow(unused)]

macro_rules! m {
    ($item: item) => { $item $item }
}

m!(use std as _;); // ERROR the name `_` is defined multiple times

fn main() {}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=a56fe430e06fcb300afcb01a64bcfe8b

@dtolnay
Copy link
Member

dtolnay commented Nov 28, 2018

Thanks @petrochenkov. If you were to ask me which of the two behaviors I would want for the code in my previous comment, I would mildly prefer for those not to be conflicting imports -- like how if a macro expands to let x: Result<_, _> = ... with the two underscores being the same token, they still operate independently and wouldn't somehow end up being constrained to be the same inferred type.

But I would be comfortable stabilizing this as currently implemented. I don't foresee the behavior being at all problematic for procedural macros in actual usage.

@Centril
Copy link
Contributor

Centril commented Nov 28, 2018

@dtolnay

like how if a macro expands to let x: Result<_, _> = ... with the two underscores being the same token, they still operate independently and wouldn't somehow end up being constrained to be the same inferred type.

I agree with this rationale and have amended the proposal accordingly.

@Nemo157
Copy link
Member

Nemo157 commented Nov 28, 2018

"Unique identifiers" (gensyms) are lost in crate metadata, so all _s become same after being imported from another crate.
This is a hard issue to solve, but it doesn't prevent the common use case of _ imports for importing tratis, which doesn't normally assume reexporting _ imports to other crates.

Re-exporting _ traits from a prelude is one of the usecases I was looking forward to. embedded_hal::prelude uses manually renamed traits to try and avoid conflicts, trying to replace this with underscore_imports compiles the crate fine, but gives an error related to this when glob imported:

error[E0428]: the name `_` is defined multiple times
  |
  = note: `_` must be defined only once in the type namespace of this module

It would be nice if there were a specific diagnostic for this usecase (and an issue to track implementing a fix?).

@petrochenkov
Copy link
Contributor Author

One more example showing that gensym creation at parse-time is at least suspicious:

duplicate! {
    // The macro argument is parsed as an unstructured token stream, `_` is parsed as a plain `_` token, gensym is not created.
    // Duplication results in two plain `_` tokens.
    // Two plain `_`s are parsed after the macro is expanded, two different gensyms are created, no name conflict happens during resolution.
    use foo as _;
}

// The macro argument is parsed as an item, gensym is created when parsing `_`.
// Duplication results in two identical gensyms.
// Two gensyms are parsed after the macro is expanded, name conflict happens during resolution.
#[duplicate]
use foo as _;

@petrochenkov
Copy link
Contributor Author

petrochenkov commented Nov 28, 2018

@Nemo157
FWIW, we can easily invert the bug, especially if gensym creation is delayed until name resolution.

Now we always consider gensyms from _ same cross-crate, while they can actually be different.
But instead we could always consider them different cross-crate, while they can actually be same.

Actually, I have hard time imagining situation in which the reverted bug would be observable, if we delay the gensym creation until resolve.
We can create a "name conflict":

// Crate 1
pub mod m {
    pub use foo as _;
}

pub use m::*;

// Crate 2
use crate1::m::*;
use crate1::*;

but it won't result in an error, because glob vs glob conflict is only an error if definitions of conflicting names are different, but in this case it's the same foo.
And apparently we can't create non-glob conflicts because gensyms from _ are unnameable.

@bors
Copy link
Contributor

bors commented Nov 29, 2018

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

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Nov 29, 2018
@petrochenkov
Copy link
Contributor Author

All the suggestions and additional tests are implemented in #56392.

@petrochenkov petrochenkov added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 30, 2018
@scottmcm
Copy link
Member

@rfcbot concern waiting-on-56392-fix

It looks like there's currently one test in https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2166-underscore-imports. Is that sufficient? Are there success stories of people trying this out and it working, so people wanting it stabilized to be able to check in? (I didn't see any in #48216, and only a failure story here.)

@petrochenkov
Copy link
Contributor Author

It looks like there's currently one test in https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2166-underscore-imports. Is that sufficient?

Well, this is a small feature. Most of intra-crate cases are basically covered in that test. (And #56392 adds some more.)

@Nemo157
Copy link
Member

Nemo157 commented Dec 1, 2018

Oh, I can give a success story where I've been using this for a while as well 😄 here I've been using it for bringing in link-only crates (and by the sounds of #56392 that will fix the allow(unused_imports) I had to use).

bors added a commit that referenced this pull request Dec 6, 2018
Delay gensym creation for "underscore items" (`use foo as _`/`const _`) until name resolution

So they cannot be cloned by macros. See #56303 for the discussion.

Mostly fix cross-crate use of underscore items by inverting the "gensyms are lost in metadata" bug as described in #56303 (comment).
Fix unused import warnings for single-segment imports (first commit) and `use crate_name as _` imports (as specified in #56303 (comment)).
Prohibit accidentally implemented `static _: TYPE = EXPR;` (cc #55983).
Add more tests for `use foo as _` imports.
@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Dec 7, 2018
@rfcbot
Copy link

rfcbot commented Dec 7, 2018

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

@petrochenkov petrochenkov added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Dec 7, 2018
@torkleyy
Copy link

Awesome! When exporting traits from a prelude like this, what is rustdoc going to generate?

@petrochenkov
Copy link
Contributor Author

@torkleyy
Some quick testing shows this:

underscore_imports

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Dec 17, 2018
@rfcbot
Copy link

rfcbot commented Dec 17, 2018

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

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Dec 17, 2018
@cramertj
Copy link
Member

r=me with @Centril's above fix to the feature gate stabilization version.

@petrochenkov
Copy link
Contributor Author

@bors r=cramertj

@bors
Copy link
Contributor

bors commented Dec 17, 2018

📌 Commit 7c901ba has been approved by cramertj

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 17, 2018
@bors
Copy link
Contributor

bors commented Dec 17, 2018

⌛ Testing commit 7c901ba with merge c9bb68f...

bors added a commit that referenced this pull request Dec 17, 2018
Stabilize `underscore_imports`

Closes #48216
@bors
Copy link
Contributor

bors commented Dec 18, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: cramertj
Pushing c9bb68f to master...

@bors bors merged commit 7c901ba into rust-lang:master Dec 18, 2018
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Mar 3, 2019
Pkgsrc changes:
 * Bump required rust version to build to 1.32.0.
 * Adapt patches to changed file locations.
 * Since we now patch some more vendor/ modules, doctor the corresponding
   .cargo-checksum.json files accordingly

Upstream changes:

Version 1.33.0 (2019-02-28)
==========================

Language
--------
- [You can now use the `cfg(target_vendor)` attribute.][57465] E.g.
  `#[cfg(target_vendor="apple")] fn main() { println!("Hello Apple!"); }`
- [Integer patterns such as in a match expression can now be exhaustive.][56362]
  E.g. You can have match statement on a `u8` that covers `0..=255` and
  you would no longer be required to have a `_ => unreachable!()` case.
- [You can now have multiple patterns in `if let` and `while let`
  expressions.][57532] You can do this with the same syntax as a `match`
  expression. E.g.
  ```rust
  enum Creature {
      Crab(String),
      Lobster(String),
      Person(String),
  }

  fn main() {
      let state = Creature::Crab("Ferris");

      if let Creature::Crab(name) | Creature::Person(name) = state {
          println!("This creature's name is: {}", name);
      }
  }
  ```
- [You can now have irrefutable `if let` and `while let` patterns.][57535]
  Using this feature will by default produce a warning as this behaviour
  can be unintuitive. E.g. `if let _ = 5 {}`
- [You can now use `let` bindings, assignments, expression statements,
  and irrefutable pattern destructuring in const functions.][57175]
- [You can now call unsafe const functions.][57067] E.g.
  ```rust
  const unsafe fn foo() -> i32 { 5 }
  const fn bar() -> i32 {
      unsafe { foo() }
  }
  ```
- [You can now specify multiple attributes in a `cfg_attr` attribute.][57332]
  E.g. `#[cfg_attr(all(), must_use, optimize)]`
- [You can now specify a specific alignment with the `#[repr(packed)]`
  attribute.][57049] E.g. `#[repr(packed(2))] struct Foo(i16, i32);` is a
  struct with an alignment of 2 bytes and a size of 6 bytes.
- [You can now import an item from a module as an `_`.][56303] This allows you
  to import a trait's impls, and not have the name in the namespace. E.g.
  ```rust
  use std::io::Read as _;

  // Allowed as there is only one `Read` in the module.
  pub trait Read {}
  ```
- [You may now use `Rc`, `Arc`, and `Pin` as method receivers][56805].

Compiler
--------
- [You can now set a linker flavor for `rustc` with the `-Clinker-flavor`
  command line argument.][56351]
- [The mininum required LLVM version has been bumped to 6.0.][56642]
- [Added support for the PowerPC64 architecture on FreeBSD.][57615]
- [The `x86_64-fortanix-unknown-sgx` target support has been upgraded to
  tier 2 support.][57130] Visit the [platform support][platform-support]
  page for information on Rust's platform support.
- [Added support for the `thumbv7neon-linux-androideabi` and
  `thumbv7neon-unknown-linux-gnueabihf` targets.][56947]
- [Added support for the `x86_64-unknown-uefi` target.][56769]

Libraries
---------
- [The methods `overflowing_{add, sub, mul, shl, shr}` are now `const`
  functions for all numeric types.][57566]
- [The methods `rotate_left`, `rotate_right`, and `wrapping_{add, sub, mul,
  shl, shr}`
  are now `const` functions for all numeric types.][57105]
- [The methods `is_positive` and `is_negative` are now `const` functions for
  all signed numeric types.][57105]
- [The `get` method for all `NonZero` types is now `const`.][57167]
- [The methods `count_ones`, `count_zeros`, `leading_zeros`, `trailing_zeros`,
  `swap_bytes`, `from_be`, `from_le`, `to_be`, `to_le` are now `const` for all
  numeric types.][57234]
- [`Ipv4Addr::new` is now a `const` function][57234]

Stabilized APIs
---------------
- [`unix::FileExt::read_exact_at`]
- [`unix::FileExt::write_all_at`]
- [`Option::transpose`]
- [`Result::transpose`]
- [`convert::identity`]
- [`pin::Pin`]
- [`marker::Unpin`]
- [`marker::PhantomPinned`]
- [`Vec::resize_with`]
- [`VecDeque::resize_with`]
- [`Duration::as_millis`]
- [`Duration::as_micros`]
- [`Duration::as_nanos`]


Cargo
-----
- [Cargo should now rebuild a crate if a file was modified during the initial
  build.][cargo/6484]

Compatibility Notes
-------------------
- The methods `str::{trim_left, trim_right, trim_left_matches,
  trim_right_matches}` are now deprecated in the standard library, and their
  usage will now produce a warning.  Please use the `str::{trim_start,
  trim_end, trim_start_matches, trim_end_matches}` methods instead.
- The `Error::cause` method has been deprecated in favor of `Error::source`
  which supports downcasting.

[55982]: rust-lang/rust#55982
[56303]: rust-lang/rust#56303
[56351]: rust-lang/rust#56351
[56362]: rust-lang/rust#56362
[56642]: rust-lang/rust#56642
[56769]: rust-lang/rust#56769
[56805]: rust-lang/rust#56805
[56947]: rust-lang/rust#56947
[57049]: rust-lang/rust#57049
[57067]: rust-lang/rust#57067
[57105]: rust-lang/rust#57105
[57130]: rust-lang/rust#57130
[57167]: rust-lang/rust#57167
[57175]: rust-lang/rust#57175
[57234]: rust-lang/rust#57234
[57332]: rust-lang/rust#57332
[57465]: rust-lang/rust#57465
[57532]: rust-lang/rust#57532
[57535]: rust-lang/rust#57535
[57566]: rust-lang/rust#57566
[57615]: rust-lang/rust#57615
[cargo/6484]: rust-lang/cargo#6484
[`unix::FileExt::read_exact_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.read_exact_at
[`unix::FileExt::write_all_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.write_all_at
[`Option::transpose`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.transpose
[`Result::transpose`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.transpose
[`convert::identity`]: https://doc.rust-lang.org/std/convert/fn.identity.html
[`pin::Pin`]: https://doc.rust-lang.org/std/pin/struct.Pin.html
[`marker::Unpin`]: https://doc.rust-lang.org/stable/std/marker/trait.Unpin.html
[`marker::PhantomPinned`]: https://doc.rust-lang.org/nightly/std/marker/struct.PhantomPinned.html
[`Vec::resize_with`]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.resize_with
[`VecDeque::resize_with`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.resize_with
[`Duration::as_millis`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_millis
[`Duration::as_micros`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_micros
[`Duration::as_nanos`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_nanos
[platform-support]: https://forge.rust-lang.org/platform-support.html
@Centril Centril added this to the 1.33 milestone Apr 26, 2019
@petrochenkov petrochenkov deleted the stabuseas branch June 5, 2019 16:24
jperkin pushed a commit to TritonDataCenter/pkgsrc that referenced this pull request Jun 20, 2019
Pkgsrc changes:
 * Bump required rust version to build to 1.32.0.
 * Adapt patches to changed file locations.
 * Since we now patch some more vendor/ modules, doctor the corresponding
   .cargo-checksum.json files accordingly

Upstream changes:

Version 1.33.0 (2019-02-28)
==========================

Language
--------
- [You can now use the `cfg(target_vendor)` attribute.][57465] E.g.
  `#[cfg(target_vendor="apple")] fn main() { println!("Hello Apple!"); }`
- [Integer patterns such as in a match expression can now be exhaustive.][56362]
  E.g. You can have match statement on a `u8` that covers `0..=255` and
  you would no longer be required to have a `_ => unreachable!()` case.
- [You can now have multiple patterns in `if let` and `while let`
  expressions.][57532] You can do this with the same syntax as a `match`
  expression. E.g.
  ```rust
  enum Creature {
      Crab(String),
      Lobster(String),
      Person(String),
  }

  fn main() {
      let state = Creature::Crab("Ferris");

      if let Creature::Crab(name) | Creature::Person(name) = state {
          println!("This creature's name is: {}", name);
      }
  }
  ```
- [You can now have irrefutable `if let` and `while let` patterns.][57535]
  Using this feature will by default produce a warning as this behaviour
  can be unintuitive. E.g. `if let _ = 5 {}`
- [You can now use `let` bindings, assignments, expression statements,
  and irrefutable pattern destructuring in const functions.][57175]
- [You can now call unsafe const functions.][57067] E.g.
  ```rust
  const unsafe fn foo() -> i32 { 5 }
  const fn bar() -> i32 {
      unsafe { foo() }
  }
  ```
- [You can now specify multiple attributes in a `cfg_attr` attribute.][57332]
  E.g. `#[cfg_attr(all(), must_use, optimize)]`
- [You can now specify a specific alignment with the `#[repr(packed)]`
  attribute.][57049] E.g. `#[repr(packed(2))] struct Foo(i16, i32);` is a
  struct with an alignment of 2 bytes and a size of 6 bytes.
- [You can now import an item from a module as an `_`.][56303] This allows you
  to import a trait's impls, and not have the name in the namespace. E.g.
  ```rust
  use std::io::Read as _;

  // Allowed as there is only one `Read` in the module.
  pub trait Read {}
  ```
- [You may now use `Rc`, `Arc`, and `Pin` as method receivers][56805].

Compiler
--------
- [You can now set a linker flavor for `rustc` with the `-Clinker-flavor`
  command line argument.][56351]
- [The mininum required LLVM version has been bumped to 6.0.][56642]
- [Added support for the PowerPC64 architecture on FreeBSD.][57615]
- [The `x86_64-fortanix-unknown-sgx` target support has been upgraded to
  tier 2 support.][57130] Visit the [platform support][platform-support]
  page for information on Rust's platform support.
- [Added support for the `thumbv7neon-linux-androideabi` and
  `thumbv7neon-unknown-linux-gnueabihf` targets.][56947]
- [Added support for the `x86_64-unknown-uefi` target.][56769]

Libraries
---------
- [The methods `overflowing_{add, sub, mul, shl, shr}` are now `const`
  functions for all numeric types.][57566]
- [The methods `rotate_left`, `rotate_right`, and `wrapping_{add, sub, mul,
  shl, shr}`
  are now `const` functions for all numeric types.][57105]
- [The methods `is_positive` and `is_negative` are now `const` functions for
  all signed numeric types.][57105]
- [The `get` method for all `NonZero` types is now `const`.][57167]
- [The methods `count_ones`, `count_zeros`, `leading_zeros`, `trailing_zeros`,
  `swap_bytes`, `from_be`, `from_le`, `to_be`, `to_le` are now `const` for all
  numeric types.][57234]
- [`Ipv4Addr::new` is now a `const` function][57234]

Stabilized APIs
---------------
- [`unix::FileExt::read_exact_at`]
- [`unix::FileExt::write_all_at`]
- [`Option::transpose`]
- [`Result::transpose`]
- [`convert::identity`]
- [`pin::Pin`]
- [`marker::Unpin`]
- [`marker::PhantomPinned`]
- [`Vec::resize_with`]
- [`VecDeque::resize_with`]
- [`Duration::as_millis`]
- [`Duration::as_micros`]
- [`Duration::as_nanos`]


Cargo
-----
- [Cargo should now rebuild a crate if a file was modified during the initial
  build.][cargo/6484]

Compatibility Notes
-------------------
- The methods `str::{trim_left, trim_right, trim_left_matches,
  trim_right_matches}` are now deprecated in the standard library, and their
  usage will now produce a warning.  Please use the `str::{trim_start,
  trim_end, trim_start_matches, trim_end_matches}` methods instead.
- The `Error::cause` method has been deprecated in favor of `Error::source`
  which supports downcasting.

[55982]: rust-lang/rust#55982
[56303]: rust-lang/rust#56303
[56351]: rust-lang/rust#56351
[56362]: rust-lang/rust#56362
[56642]: rust-lang/rust#56642
[56769]: rust-lang/rust#56769
[56805]: rust-lang/rust#56805
[56947]: rust-lang/rust#56947
[57049]: rust-lang/rust#57049
[57067]: rust-lang/rust#57067
[57105]: rust-lang/rust#57105
[57130]: rust-lang/rust#57130
[57167]: rust-lang/rust#57167
[57175]: rust-lang/rust#57175
[57234]: rust-lang/rust#57234
[57332]: rust-lang/rust#57332
[57465]: rust-lang/rust#57465
[57532]: rust-lang/rust#57532
[57535]: rust-lang/rust#57535
[57566]: rust-lang/rust#57566
[57615]: rust-lang/rust#57615
[cargo/6484]: rust-lang/cargo#6484
[`unix::FileExt::read_exact_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.read_exact_at
[`unix::FileExt::write_all_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.write_all_at
[`Option::transpose`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.transpose
[`Result::transpose`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.transpose
[`convert::identity`]: https://doc.rust-lang.org/std/convert/fn.identity.html
[`pin::Pin`]: https://doc.rust-lang.org/std/pin/struct.Pin.html
[`marker::Unpin`]: https://doc.rust-lang.org/stable/std/marker/trait.Unpin.html
[`marker::PhantomPinned`]: https://doc.rust-lang.org/nightly/std/marker/struct.PhantomPinned.html
[`Vec::resize_with`]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.resize_with
[`VecDeque::resize_with`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.resize_with
[`Duration::as_millis`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_millis
[`Duration::as_micros`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_micros
[`Duration::as_nanos`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_nanos
[platform-support]: https://forge.rust-lang.org/platform-support.html
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking issue for RFC #2166: impl-only-use
9 participants