See Issue 8142 for discussion.
This makes it illegal for a Drop impl to be more specialized than the
original item.
So for example, all of the following are now rejected (when they would
have been blindly accepted before):
```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type
struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region
struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement
struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```
Due to examples like the above, this is a [breaking-change].
(The fix is to either remove the specialization from the `Drop` impl,
or to transcribe the requirements into the struct/enum definition;
examples of both are shown in the PR's fixed to `libstd`.)
----
This is likely to be the last thing blocking the removal of the
`#[unsafe_destructor]` attribute.
Includes two new error codes for the new dropck check.
Update run-pass tests to accommodate new dropck pass.
Update tests and docs to reflect new destructor restriction.
----
Implementation notes:
We identify Drop impl specialization by not being as parametric as the
struct/enum definition via unification.
More specifically:
1. Attempt unification of a skolemized instance of the struct/enum
with an instance of the Drop impl's type expression where all of
the impl's generics (i.e. the free variables of the type
expression) have been replaced with unification variables.
2. If unification fails, then reject Drop impl as specialized.
3. If unification succeeds, check if any of the skolemized
variables "leaked" into the constraint set for the inference
context; if so, then reject Drop impl as specialized.
4. Otherwise, unification succeeded without leaking skolemized
variables: accept the Drop impl.
We identify whether a Drop impl is injecting new predicates by simply
looking whether the predicate, after an appropriate substitution,
appears on the struct/enum definition.
The first commit adds a short note which I believe will reduce worries in people who work with closures very often and read the Rust book for their first time.
The second commit consists solely of tiny typo fixes. In some cases, I changed "logical" quotations like
She said, "I like programming".
to
She said, "I like programming."
because the latter seems to be the prevalent style in the book.
After PR #19766 added implicit coersions `*mut T -> *const T`, the explicit casts can be removed.
(The number of such casts turned out to be relatively small).
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
"Idiomatic code should not use extra whitespace in the middle of a line to provide alignment."
http://aturon.github.io/style/whitespace.html
I realize the linked page still needs an RFC, but the docs should be written in accordance with the guidelines nevertheless.
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
This commit is an attempt to standardize the use of punctuation and
formatting in "The Rust Programming Language" as discussed in #19823.
- Convert bold text to italicized textcwhen referring to terminology.
- Convert single-quoted text to italicized or double-quoted text,
depending on context.
- Use double quotes only in the case of scare quotes or quotations.
