Deprecate the AsciiExt trait in favor of inherent methods
The trait and some of its methods are stable and will remain.
Some of the newer methods are unstable and can be removed later.
Fixes https://github.com/rust-lang/rust/issues/39658
Add BufReader::buffer
This subsumes the need for an explicit is_empty function, and provides
access to the buffered data itself which has been requested from time to
time.
We could call this `buf` to match `fill_buf`, but I think I'd prefer `fill_buffer` anyways in hindsight.
The expected behavior is that the environment's PATH should be used
to find the process. posix_spawn() could be used if we iterated
PATH to search for the binary to execute. For now just skip
posix_spawn() if PATH is modified.
rustc: Enable embedding LLVM bitcode for iOS
This commit updates rustc to embed bitcode in each object file generated by
default when compiling for iOS. This was determined in #35968 as a step
towards better compatibility with the iOS toolchain, so let's give it a spin and
see how it turns out!
Note that this also updates the `cc` dependency which should propagate this
change of embedding bitcode for C dependencies as well.
Make `assert` a built-in procedural macro
Makes `assert` macro a built-in one without touching its functionality. This is a prerequisite for RFC 2011 (#44838).
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?
This commit updates rustc to embed bitcode in each object file generated by
default when compiling for iOS. This was determined in #35968 as a step
towards better compatibility with the iOS toolchain, so let's give it a spin and
see how it turns out!
Note that this also updates the `cc` dependency which should propagate this
change of embedding bitcode for C dependencies as well.
* Pass `opt_level(2)` when calculating CFLAGS to get the right flags on iOS
* Unconditionally pass `-O2` when compiling libbacktrace
This should...
Close#48903Close#48906
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.
As per issue #43601, types that can change size depending on the
target operating system should say so in their documentation.
I used this template when adding doc comments:
The size of a(n) <name> struct may vary depending on the target
operating system, and may change between Rust releases.
For enums, I used "instance" instead of "struct".
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 [...]
