| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enable LVI hardening for x86_64-fortanix-unknown-sgx
This implements mitigations for the Load Value Injection vulnerability (CVE-2020-0551) for the `x86_64-fortanix-unknown-sgx` target by enabling new LLVM passes. More information about LVI and mitigations may be found at https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection.
This PR unconditionally enables the mitigations for `x86_64-fortanix-unknown-sgx` since there is no available hardware that doesn't require the mitigations. This may be reconsidered in the future.
* [x] This depends on https://github.com/rust-lang/compiler-builtins/pull/359/
|
|
unchecked.
Doc tests have been written and the documentation on the error type
updated too.
|
|
Co-authored-by: LeSeulArtichaut <leseulartichaut@gmail.com>
|
|
Cstring `from_raw` and `into_raw` safety precisions
Fixes #48525.
Fixes #68456.
This issue had two points:
- The one about `from_raw` has been addressed (I hope).
- The other one, about `into_raw`, has only been partially fixed.
About `into_raw`: the idea was to:
> steer users away from using the pattern of CString::{into_raw,from_raw} when interfacing with C APIs that may change the effective length of the string by writing interior NULs or erasing the final NUL
I tried making a `Vec<c_char>` like suggested but my current solution feels very unsafe and *hacky* to me (most notably the type cast), I included it here to make it available for discussion:
```rust
fn main() {
use std::os::raw::c_char;
let v = String::from("abc")
.bytes()
// From u8 to i8,
// I feel like it will be a problem for values of u8 > 255
.map(|c| c as c_char)
.collect::<Vec<_>>();
dbg!(v);
}
```
|
|
Added the documentation for the 'use' keyword
This is a partial fix of #34601.
I heavily inspired myself from the Reference on the `use` keyword.
I checked the links when compiling the documentation, they should be ok.
I also added an example for the wildcard `*` in the case of types, because it's behaviour is not *import everything* like one might think at first.
|
|
mutex holding it
|
|
|
|
|
|
Bump bootstrap compiler to 1.45
Pretty standard update.
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize `std::io::Buf{Reader, Writer}::capacity`
Closes #68833
FCP is done here: https://github.com/rust-lang/rust/issues/68833#issuecomment-637596083
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #72683 (from_u32_unchecked: check validity, and fix UB in Wtf8)
- #72715 (Account for trailing comma when suggesting `where` clauses)
- #72745 (generalize Borrow<[T]> for Interned<'tcx, List<T>>)
- #72749 (Update stdarch submodule to latest head)
- #72781 (Use `LocalDefId` instead of `NodeId` in `resolve_str_path_error`)
Failed merges:
r? @ghost
|
|
from_u32_unchecked: check validity, and fix UB in Wtf8
Fixes https://github.com/rust-lang/rust/issues/72760
|
|
Update compiler-builtins
Pulls in a fix for #72758, more details on the linked issue.
[Crate changes included here][changes]
[changes]: https://github.com/rust-lang/compiler-builtins/compare/0.1.28...0.1.31
Closes #72758
|
|
|
|
Fix suggestions from review.
Co-authored-by: Bastian Kauschke <bastian_kauschke@hotmail.de>
|
|
|
|
|
|
|
|
Add Extend::{extend_one,extend_reserve}
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
|
|
|
|
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
|
|
Rollup of 9 pull requests
Successful merges:
- #67460 (Tweak impl signature mismatch errors involving `RegionKind::ReVar` lifetimes)
- #71095 (impl From<[T; N]> for Box<[T]>)
- #71500 (Make pointer offset methods/intrinsics const)
- #71804 (linker: Support `-static-pie` and `-static -shared`)
- #71862 (Implement RFC 2585: unsafe blocks in unsafe fn)
- #72103 (borrowck `DefId` -> `LocalDefId`)
- #72407 (Various minor improvements to Ipv6Addr::Display)
- #72413 (impl Step for char (make Range*<char> iterable))
- #72439 (NVPTX support for new asm!)
Failed merges:
r? @ghost
|
|
|
|
Pulls in a fix for #72758, more details on the linked issue.
[Crate changes included here][changes]
[changes]: https://github.com/rust-lang/compiler-builtins/compare/0.1.28...0.1.31
|
|
Various minor improvements to Ipv6Addr::Display
Cleaned up `Ipv6Addr::Display`, especially with an eye towards simplifying and reducing duplicated logic. Also added a fast-path optimization, similar to #72399 and #72398.
- Defer to `Ipv4Addr::fmt` when printing an Ipv4 address
- Fast path: write directly to `f` without an intermediary buffer when there are no alignment options
- Simplify finding the inner zeroes-span
|
|
Implement total_cmp for f32, f64
# Overview
* Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that, unlike the standard `partial_cmp`, is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate.
* The method has an API similar to `cmp`: `pub fn total_cmp(&self, other: &Self) -> crate::cmp::Ordering { ... }`.
* Implements tests.
* Has documentation.
# Justification for the API
* Total ordering for `f32` and `f64` has been discussed many time before:
* https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701
* https://github.com/rust-lang/rfcs/issues/1249
* https://github.com/rust-lang/rust/pull/53938
* https://github.com/rust-lang/rust/issues/5585
* The lack of total ordering leads to frequent complaints, especially from people new to Rust.
* This is an ergonomics issue that needs to be addressed.
* However, the default behaviour of implementing only `PartialOrd` is intentional, as relaxing it might lead to correctness issues.
* Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is, however not easy to add because of the large API surface added.
* As a minimal step that hopefully proves uncontroversial, we can implement a stand-alone method `total_cmp` on floating point types.
* I expect adding such methods should be uncontroversial because...
* Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day.
* It implements functionality that is standardised. (IEEE 754, 2008 rev. §5.10 Note, that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.)
* With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion, providing additional helper methods is a minimal way of adding ordering functionality.
* Not also does it allow easily using aforementioned APIs, it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper, if needed.
|
|
SocketAddr and friends now correctly pad its content
Currently, `IpAddr` and friends correctly respect formatting parameters when printing via `Display`. This PR makes SocketAddr and friends do the same thing.
|
|
Impl Error for Infallible
This PR only changes the place where `impl Error for Infallible` is documented, as one could think that it is not the case when reading https://doc.rust-lang.org/nightly/std/convert/enum.Infallible.html.
Fixes #70842
|
|
|
|
|
|
IpAddr and friends pad when displaying; SocketAddr now does this as well
|
|
Implement PartialOrd and Ord for SocketAddr*
The implementation is mostly the same as the one found in `IpAddr` (other than adding comparison for ports, of course).
Continues #53788 and #53863
Fixes #53710
|
|
|
|
This is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
|
|
|
