Fixes#63677
RFC #2071 (impl-trait-existential-types) does not explicitly state how
impl trait type alises should interact with coherence. However, there's
only one choice which makes sense - coherence should look at the
underlying type (i.e. the 'defining' type of the impl trait) of the type
alias, just like we do for non-impl-trait type aliases.
Specifically, impl trait type alises which resolve to a local type
should be treated like a local type with respect to coherence (e.g.
impl trait type aliases which resolve to a forieign type should be
treated as a foreign type, and those that resolve to a local type should
be treated as a local type).
Since neither inherent impls nor direct trait impl (i.e. `impl MyType`
or `impl MyTrait for MyType`) are allowd for type aliases, this
usually does not come up. Before we ever attempt to do coherence
checking, we will have errored out if an impl trait type alias was used
directly in an 'impl' clause.
However, during trait selection, we sometimes need to prove bounds like
'T: Sized' for some type 'T'. If 'T' is an impl trait type alias, this
requires to know the coherence behavior for impl trait type aliases when
we perform coherence checking.
Note: Since determining the underlying type of an impl trait type alias
requires us to perform body type checking, this commit causes us to type
check some bodies easlier than we otherwise would have. However, since
this is done through a query, this shouldn't cause any problems
For completeness, I've added an additional test of the coherence-related
behavior of impl trait type aliases.
We are going to uniform the terminology of all associated items.
Methods that may or may not have `self` are called "associated
functions". Because `AssociatedFn` is a bit long, we rename `Associated`
to `Assoc`.
lint: convert incoherent_fundamental_impls into hard error
*Summary for affected authors:* If your crate depends on one of the following crates, please upgrade to a newer version:
- gtk-rs: upgrade to at least 0.4
- rusqlite: upgrade to at least 0.14
- nalgebra: upgrade to at least 0.15, or the last patch version of 0.14
- spade: upgrade or refresh the Cargo.lock file to use version 1.7
- imageproc: upgrade to at least 0.16 (newer versions no longer use nalgebra)
implement #46205
r? @nikomatsakis
add coherence future-compat warnings for marker-only trait objects
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
Note: this lint should be made to default-warn before we merge. It is deny only for the crater run.
r? @nikomatsakis / @scalexm . cc @Centril & @alexreg.
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
It should be possible to revert this commit when we're done with the
warnings.
dropping the param-env on the floor is obviously the wrong thing to do.
The ICE was probably exposed by #54490 adding the problem-exposing use of
`traits::find_associated_item`.
Fixes#55380.
Rollup of 17 pull requests
Successful merges:
- #55182 (Redox: Update to new changes)
- #55211 (Add BufWriter::buffer method)
- #55507 (Add link to std::mem::size_of to size_of intrinsic documentation)
- #55530 (Speed up String::from_utf16)
- #55556 (Use `Mmap` to open the rmeta file.)
- #55622 (NetBSD: link libstd with librt in addition to libpthread)
- #55750 (Make `NodeId` and `HirLocalId` `newtype_index`)
- #55778 (Wrap some query results in `Lrc`.)
- #55781 (More precise spans for temps and their drops)
- #55785 (Add mem::forget_unsized() for forgetting unsized values)
- #55852 (Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint)
- #55865 (Unix RwLock: avoid racy access to write_locked)
- #55901 (fix various typos in doc comments)
- #55926 (Change sidebar selector to fix compatibility with docs.rs)
- #55930 (A handful of hir tweaks)
- #55932 (core/char: Speed up `to_digit()` for `radix <= 10`)
- #55956 (add tests for some fixed ICEs)
Failed merges:
r? @ghost
Reattach all grandchildren when constructing specialization graph.
Specialization graphs are constructed by incrementally adding impls in the order of declaration. If the impl being added has its specializations in the graph already, they should be reattached under the impl. However, the current implementation only reattaches the one found first. Therefore, in the following specialization graph,
```
Tr1
|
I3
/ \
I1 I2
```
If `I1`, `I2`, and `I3` are declared in this order, the compiler mistakenly constructs the following graph:
```
Tr1
/ \
I3 I2
|
I1
```
This patch fixes the reattach procedure to include all specializing grandchildren-to-be.
Fixes#50452.
This seemed like a good way to kick the tires on the
elided-lifetimes-in-paths lint (#52069)—seems to work! This was also
pretty tedious—it sure would be nice if `cargo fix` worked on this
codebase (#53896)!
