In #28864, @aarzee submitted some whitespace fixes. I r+'d it. But
@retp998 noticed[1] that this file is explicitly a test of this kind of
whitespace, and so I shouldn't have changed it. This restores the old
line endings.
1: https://github.com/rust-lang/rust/pull/28864#discussion_r41332279
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`.
(It is not *exactly* the text from the RFC, but the only thing it adds
is a call to a no-op function that is just an attempt to make it clear
where the potential for impl specialization comes from.)
One just checks that we are feature-gating the UGEH attribute (as
usual for attributes associated with unstable features).
The other is adapted from the RFC 1238 text, except that it has been
extended somewhat to actually *illustrate* the scenario that we are
trying to prevent, namely observing the state of data, from safe code,
after the destructor for that data has been executed.
Illustrates cases that worked before and must continue to work, and a
case that shows how to use the `unsafe_destructor_blind_to_params`
attribute (aka "the UGEH attribute") to work around
cannot-assume-parametricity.
I needed it in `RawVec`, `Vec`, and `TypedArena` for `rustc` to
bootstrap; but of course that alone was not sufficient for `make
check`.
Later I added `unsafe_destructor_blind_to_params` to collections, in
particular `LinkedList` and `RawTable` (the backing representation for
`HashMap` and `HashSet`), to get the regression tests exercising
cyclic structure from PR #27185 building.
----
Note that the feature is `dropck_parametricity` (which is not the same
as the attribute's name). We will almost certainly vary our strategy
here in the future, so it makes some sense to have a not-as-ugly name
for the feature gate. (The attribute name was deliberately selected to
be ugly looking.)
Implement cannot-assume-parametricity (CAP) from RFC 1238, and add the
UGEH attribute.
----
Note that we check for the attribute attached to the dtor method, not
the Drop impl.
(This is just to match the specification of RFC and the tests; I am
not wedded to this approach.)
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.
I had to fix a few things. Notable changes:
1. I removed the MIR support for constants, instead falling back to the existing `ConstVal`. I still think we ought to reform how we handle constants, but it's not clear to me that the approach I was taking is correct, and anyway I think we ought to do it separately.
2. I adjusted how we handle bindings in matches: we now *declare* all the bindings up front, rather than doing it as we encounter them. This is not only simpler, since we don't have to check if a binding has already been declared, it avoids ICEs if any of the arms turn out to be unreachable.
3. I do MIR construction *after* `check_match`, because it detects various broken cases. I'd like for `check_match` to be subsumed by MIR construction, but we can do that as a separate PR (if indeed it makes sense).
I did a crater run and found no regressions in the wild: https://gist.github.com/nikomatsakis/0038f90e10c8ad00f2f8
