These common traits were left off originally by accident from these smart
pointers, and a past attempt (#26008) to add them was later reverted (#26160)
due to unexpected breakge (#26096) occurring. The specific breakage in worry is
the meaning of this return value changed:
let a: Box<Option<T>> = ...;
a.as_ref()
Currently this returns `Option<&T>` but after this change it will return
`&Option<T>` because the `AsRef::as_ref` method shares the same name as
`Option::as_ref`. A [crater report][crater] of this change, however, has shown
that the fallout of this change is quite minimal. These trait implementations
are "the right impls to add" to these smart pointers and would enable various
generalizations such as those in #27197.
[crater]: https://gist.github.com/anonymous/0ba4c3512b07641c0f99
This commit is a breaking change for the above reasons mentioned, and the
mitigation strategies look like any of:
Option::as_ref(&a)
a.as_ref().as_ref()
(*a).as_ref()
This commit contains some of the changes proposed by a rustfmt invocation,
chosen based on the fairly non-deterministic metric of how much I liked the
change. I expect we will run rustfmt on this crate again later, probably
accepting more of its changes. For now, this is already an improvement over
the status-quo.
This commit contains some of the changes proposed by a rustfmt invocation,
chosen based on the fairly non-deterministic metric of how much I liked the
change. I expect we will run rustfmt on this crate again later, probably
accepting more of its changes. For now, this is already an improvement over
the status-quo.
This turned up as part of #3170. When constructing an `undef` value to
return in the error case, we were trying to get the element type of the
Rust-level value being indexed instead of the underlying array; when
indexing a slice, that's not an array and the LLVM assertion failure
reflects this.
The regression test is a lightly altered copy of `const-array-oob.rs`.
This lint warning was originally intended to help against misuse of the old Rust
`int` and `uint` types in FFI bindings where the Rust `int` was not equal to the
C `int`. This confusion no longer exists (as Rust's types are now `isize` and
`usize`), and as a result the need for this lint has become much less over time.
Additionally, starting with [the RFC for libc][rfc] it's likely that `isize` and
`usize` will be quite common in FFI bindings (e.g. they're the definition of
`size_t` and `ssize_t` on many platforms).
[rfc]: https://github.com/rust-lang/rfcs/pull/1291
This commit disables these lints to instead consider `isize` and `usize` valid
types to have in FFI signatures.
Part of #28710
Landing pads during stage0 are now enabled by defaullt. Since this has its downsides and upsides either way, I made it possible to change the option through configure.
