The methods on the structures `fs::FileType` and `fs::Metadata` of (respectively) `is_file`, `is_dir`, and
`is_symlink` had some ambiguity in documentation, where it was not noted whether files will pass those tests
exclusively or not. It is now written that the tests are mutually exclusive.
Fixes#48345.
Stabilize inclusive range (`..=`)
Stabilize the followings:
* `inclusive_range` — The `std::ops::RangeInclusive` and `std::ops::RangeInclusiveTo` types, except its fields (tracked by #49022 separately).
* `inclusive_range_syntax` — The `a..=b` and `..=b` expression syntax
* `dotdoteq_in_patterns` — Using `a..=b` in a pattern
cc #28237
r? @rust-lang/lang
Replace feature(never_type) with feature(exhaustive_patterns).
feature(exhaustive_patterns) only covers the pattern-exhaustives checks
that used to be covered by feature(never_type)
Move ascii::escape_default to libcore
As requested in #46409, the `ascii::escape_default` method has been added to the core library. All I did was copy over the `std::ascii` module file, remove the (redundant) `AsciiExt` trait, and change some of the documentation to match. None of the tests were changed.
I wasn't sure how to handle the annotations. For `EscapeDefault` and `escape_default()`, I changed them to `#[unstable(feature = "core_ascii", issue = "46409")]`. Is that alright? Or should I leave them as they were?
Required moving all fulldeps tests depending on `rand` to different locations as
now there's multiple `rand` crates that can't be implicitly linked against.
Modify part of `column!` documentation.
Just like `line!` documentation, I've replaced:
> The returned column is not the invocation of the `column!` macro itself
By
> The returned column is *not necessarily* the line of the `column!` invocation itself
See #46997.
Modify part of `line!` documentation.
In accordance with #46997, I've replaced:
> The returned line is not the invocation of the line! macro itself [...]
By
> The returned line is *not necessarily* the line of the `line!` invocation itself [...]
Just like `line!` documentation, I've replaced:
> The returned column is not the invocation of the `column!` macro itself
By
> The returned column is *not necessarily* the line of the `column!` invocation itself
See #46997.
In accordance with #46997, I've replaced:
> The returned line is not the invocation of the line! macro itself [...]
By
> The returned line is *not necessarily* the line of the `line!` invocation itself [...]
Stabilize FusedIterator
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Closes#35602
std: Add `arch` and `simd` modules
This commit imports the `stdsimd` crate into the standard library,
creating an `arch` and `simd` module inside of both libcore and libstd.
Both of these modules are **unstable** and will continue to be so until
RFC 2335 is stabilized.
As a brief recap, the modules are organized as so:
* `arch` contains all current architectures with intrinsics, for example
`std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These
modules contain all of the intrinsics defined for the platform, like
`_mm_set1_epi8`.
* In the standard library, the `arch` module also exports a
`is_target_feature_detected` macro which performs runtime detection to
determine whether a target feature is available at runtime.
* The `simd` module contains experimental versions of strongly-typed
lane-aware SIMD primitives, to be fully fleshed out in a future RFC.
The main purpose of this commit is to start pulling in all these
intrinsics and such into the standard library on nightly and allow
testing and such. This'll help allow users to easily kick the tires and
see if intrinsics work as well as allow us to test out all the
infrastructure for moving the intrinsics into the standard library.
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
This commit imports the `stdsimd` crate into the standard library,
creating an `arch` and `simd` module inside of both libcore and libstd.
Both of these modules are **unstable** and will continue to be so until
RFC 2335 is stabilized.
As a brief recap, the modules are organized as so:
* `arch` contains all current architectures with intrinsics, for example
`std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These
modules contain all of the intrinsics defined for the platform, like
`_mm_set1_epi8`.
* In the standard library, the `arch` module also exports a
`is_target_feature_detected` macro which performs runtime detection to
determine whether a target feature is available at runtime.
* The `simd` module contains experimental versions of strongly-typed
lane-aware SIMD primitives, to be fully fleshed out in a future RFC.
The main purpose of this commit is to start pulling in all these
intrinsics and such into the standard library on nightly and allow
testing and such. This'll help allow users to easily kick the tires and
see if intrinsics work as well as allow us to test out all the
infrastructure for moving the intrinsics into the standard library.
Stabilize LocalKey::try_with
The `LocalKey::try_with` method is now stabilized.
`LocalKey::state` and `LocalKeyState` marked as deprecated. Although, is there any reason to keep them - should we perhaps remove them completely?
Closes#27716
r? @alexcrichton
Restrict the Termination impls to simplify stabilization
Make a minimal commitment in preparation for stabilization. More impls, or broader ones, are likely in future, but are not necessary at this time and are more controversial.
cc https://github.com/rust-lang/rust/issues/48453#issuecomment-368155082
r? @nikomatsakis
Comprehensively support trailing commas in std/core macros
I carefully organized the changes into four commits:
* Test cases
* Fixes for `macro_rules!` macros
* Fixes for builtin macros
* Docs for builtins
**I can easily scale this back to just the first two commits for now if such is desired.**
### Breaking (?) changes
* This fixes#48042, which is a breaking change that I hope people can agree is just a bugfix for an extremely dark corner case.
* To fix five of the builtins, this changes `syntax::ext::base::get_single_str_from_tts` to accept a trailing comma, and revises the documentation so that this aspect is not surprising. **I made this change under the (hopefully correct) understanding that `libsyntax` is private rustc implementation detail.** After reviewing all call sites (which were, you guessed it, *precisely those five macros*), I believe the revised semantics are closer to the intended spirit of the function.
### Changes which may require concensus
Up until now, it could be argued that some or all the following macros did not conceptually take a comma-separated list, because they only took one argument:
* **`cfg(unix,)`** (most notable since cfg! is unique in taking a meta tag)
* **`include{,_bytes,_str}("file.rs",)`** (in item form this might be written as "`include!{"file.rs",}`" which is even slightly more odd)
* **`compile_error("message",);`**
* **`option_env!("PATH",)`**
* **`try!(Ok(()),)`**
So I think these particular changes may require some sort of consensus. **All of the fixes for builtins are included this list, so if we want to defer these decisions to later then I can scale this PR back to just the first two commits.**
### Other notes/general requests for comment
* Do we have a big checklist somewhere of "things to do when adding macros?" My hope is for `run-pass/macro-comma-support.rs` to remain comprehensive.
* Originally I wanted the tests to also comprehensively forbid double trailing commas. However, this didn't work out too well: [see this gist and the giant FIXME in it](https://gist.github.com/ExpHP/6fc40e82f3d73267c4e590a9a94966f1#file-compile-fail_macro-comma-support-rs-L33-L50)
* I did not touch `select!`. It appears to me to be a complete mess, and its trailing comma mishaps are only the tip of the iceberg.
* There are [some compile-fail test cases](5fa97c35da/src/test/compile-fail/macro-comma-behavior.rs (L49-L52)) that didn't seem to work (rustc emits errors, but compile-fail doesn't acknowledge them), so they are disabled. Any clues? (Possibly related: These happen to be precisely the set of errors which are tagged by rustc as "this error originates in a macro outside of the current crate".)
---
Fixes#48042Closes#46241
