PR #22012 followup: clean up vtable::check_object_cast by reusing `fresh_ty`
(hat tip to nikomatsakis, who was the one who pointed out this simplification to the logic.)
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Closes#8962Closes#16360Closes#20327
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.
Closes#8962Closes#16360Closes#20327
[breaking-change]
This is a resurrection and heavy revision/expansion of a PR that pcwalton did to resolve#8861.
The most relevant, user-visible semantic change is this: #[unsafe_destructor] is gone. Instead, if a type expression for some value has a destructor, then any lifetimes referenced within that type expression must strictly outlive the scope of the value.
See discussion on https://github.com/rust-lang/rfcs/pull/769
Handles e.g. `impl<T> Drop for Vec<T>` as parametric: If `T` does not
have any drop code that could read from borrowed data of lifetime `'a`,
then we infer that the drop code for `Vec<T>` also cannot read from
borrowed data of lifetime `'a`, and therefore we do not need to inject
the SafeDestructor constraint for it.
Notably, this enables us to continue storing cyclic structure, without
any `unsafe` code, in `Vec`, without allowing (unsound) destructors on
such cyclic data. (Later commits have tests illustrating these two
cases in run-pass and compile-fail, respectively.)
(This is "Condition (B.)" in Drop-Check rule described in RFC 769.)
Largely adapted from pcwalton's original branch, with following
notable modifications:
Use `regionck::type_must_outlive` to generate `SafeDestructor`
constraints. (this plugged some soundness holes in the analysis).
Avoid exponential time blowup on compile-fail/huge-struct.rs by
keeping the breadcrumbs until end of traversal.
Avoid premature return from regionck::visit_expr.
Factored drop-checking code out into dropck module.
Added `SafeDestructor` to enum `SubregionOrigin` (for error reporting).
----
Since this imposes restrictions on the lifetimes used in types with
destructors, this is a (wait for it)
[breaking-change]
immediately surrounding a node that is a terminating_scope
(e.g. statements, looping forms) during which the destructors run (the
destructors for temporaries from the execution of that node, that is).
Introduced DestructionScopeData newtype wrapper around ast::NodeId, to
preserve invariant that FreeRegion and ScopeChain::BlockScope carry
destruction scopes (rather than arbitrary CodeExtents).
Insert DestructionScope and block Remainder into enclosing CodeExtents
hierarchy.
Add more doc for DestructionScope, complete with ASCII art.
Switch to constructing DestructionScope rather than Misc in a number
of places, mostly related to `ty::ReFree` creation, and use
destruction-scopes of node-ids at various calls to
liberate_late_bound_regions.
middle::resolve_lifetime: Map BlockScope to DestructionScope in `fn resolve_free_lifetime`.
Add the InnermostDeclaringBlock and InnermostEnclosingExpr enums that
are my attempt to clarify the region::Context structure, and that
later commmts build upon.
Improve the debug output for `CodeExtent` attached to `ty::Region::ReScope`.
Loosened an assertion in `rustc_trans::trans::cleanup` to account for
`DestructionScope`. (Perhaps this should just be switched entirely
over to `DestructionScope`, rather than allowing for either `Misc` or
`DestructionScope`.)
----
Even though the DestructionScope is new, this particular commit should
not actually change the semantics of any current code.
Given `<expr> as Box<Trait>`, infer that `Box<_>` is expected type for `<expr>`.
This is useful for addressing fallout from newly proposed box protocol; see #22006 for examples of such fallout, much of which will be unnecessary with this fix.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
r? @alexcrichton
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
upgrade the inference based on expected type so that it is able to
infer the fn kind in isolation even if the full signature is not
available (and we could perhaps do better still in some cases, such as
extracting just the types of the arguments but not the return value).
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Closes#21420.
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Closes#21420.
For "symmetric" binary operators, meaning the types of two sides must be
equal, if the type of LHS doesn't know yet but RHS does, use that as an
hint to infer LHS' type.
Closes#21634
specialized to closures, and invoke them as soon as we know the
closure kind. I thought initially we would need a fixed-point
inference algorithm but it appears I was mistaken, so we can do this.
upvar inference. Upvar inference can cause some obligations to be
deferred, notably things like `F : Sized` where `F` is a closure type,
or `F : FnMut`. Adjust the ordering therefore so that we process all
traits and apply fallback, do upvar inference, and only then start
reporting errors for outstanding obligations.
doing the final checking for closure calls until after trait inference
is performed. This isn't important now, but it's essential if we are to
delay inferring the closure kind.
