bors [Tue, 23 Jun 2020 07:50:51 +0000 (07:50 +0000)]
Auto merge of #73643 - Manishearth:rollup-68dr8fz, r=Manishearth
Rollup of 9 pull requests
Successful merges:
- #72271 (Improve compiler error message for wrong generic parameter order)
- #72493 ( move leak-check to during coherence, candidate eval)
- #73398 (A way forward for pointer equality in const eval)
- #73472 (Clean up E0689 explanation)
- #73496 (Account for multiple impl/dyn Trait in return type when suggesting `'_`)
- #73515 (Add second message for LiveDrop errors)
- #73567 (Clarify --extern documentation.)
- #73572 (Fix typos in doc comments)
- #73590 (bootstrap: no `config.toml` exists regression)
Rollup merge of #73515 - christianpoveda:livedrop-diagnostics, r=oli-obk
Add second message for LiveDrop errors
This is an attempt to fix https://github.com/rust-lang/rust/issues/72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> src/lib.rs:7:9
|
7 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
error: aborting due to previous error
```
to this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> foo.rs:6:9
|
6 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
...
10 | always_returned = never_returned;
| --------------- value is dropped here
error: aborting due to previous error
```
r? @RalfJung @ecstatic-morse
Rollup merge of #72493 - nikomatsakis:move-leak-check, r=matthewjasper
move leak-check to during coherence, candidate eval
Implementation of MCP https://github.com/rust-lang/compiler-team/issues/295.
I'd like to do a crater run on this.
Note to @rust-lang/lang: This PR is a breaking change (bugfix). It causes tests like the following to go from a future-compatibility warning #56105 to a hard error:
```rust
trait Trait {}
impl Trait for for<'a, 'b> fn(&'a u32, &'b u32) {}
impl Trait for for<'c> fn(&'c u32, &'c u32) {} // now rejected, used to warn
```
I am not aware of any instances of this code in the wild, but that is why we are doing a crater run. The reason for this change is that those two types are, in fact, the same type, and hence the two impls are overlapping.
There will still be impls that trigger #56105 after this lands, however -- I hope that we will eventually just accept those impls without warning, for the most part. One example of such an impl is this pattern, which is used by wasm-bindgen and other crates as well:
```rust
trait Trait {}
impl<T> Trait for fn(&T) { }
impl<T> Trait for fn(T) { } // still accepted, but warns
```
bors [Tue, 23 Jun 2020 04:03:28 +0000 (04:03 +0000)]
Auto merge of #73635 - Dylan-DPC:rollup-b4wbp42, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #71756 (add Windows system error codes that should map to io::ErrorKind::TimedOut)
- #73495 (Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits)
- #73575 (Fix typo in error_codes doc)
- #73578 (Make is_freeze and is_copy_modulo_regions take TyCtxtAt)
- #73586 (switch_ty is redundant)
- #73600 (Fix spurious 'value moved here in previous iteration of loop' messages)
- #73610 (Clean up E0699 explanation)
Dylan DPC [Tue, 23 Jun 2020 01:16:26 +0000 (03:16 +0200)]
Rollup merge of #73600 - Aaron1011:fix/move-in-macro, r=ecstatic-morse
Fix spurious 'value moved here in previous iteration of loop' messages
Fixes #46099
Previously, we would check the 'move' and 'use' spans to see if we
should emit this message. However, this can give false positives when
macros are involved, since two distinct expressions may end up with the
same span.
Instead, we check the actual MIR `Location`, which eliminates false
positives.
Dylan DPC [Tue, 23 Jun 2020 01:16:24 +0000 (03:16 +0200)]
Rollup merge of #73586 - RalfJung:switch-ty, r=oli-obk
switch_ty is redundant
This field is redundant, but we cannot remove it currently as pretty-printing relies on it (and it does not have access to `mir::Body` to compute the type itself).
Dylan DPC [Tue, 23 Jun 2020 01:16:19 +0000 (03:16 +0200)]
Rollup merge of #73495 - Lucretiel:wasi-io-impls, r=sfackler
Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits
Currently, some of the platform-specific standard streams (`src/libstd/sys/*/stdio.rs`) manually implement parts of the `io::Write` interface directly as methods on the struct, rather than by actually implementing the trait. There doesn't seem to be any reason for this, other than an unused advantage of `fn write(&self, ...)` instead of `fn write(&mut self, ...)`.
Unfortunately, this means that those implementations don't have the default-implemented io methods, like `read_exact` and `write_all`. This caused #72705, which adds forwarding methods to the user-facing standard stream implementations, to fail to compile on those platforms.
This change converts *all* such standard stream structs to use the standard library traits. This change should not cause any breakages, because the changed types are not publicly exported, and in fact are only ever used in `src/libstd/io/stdio.rs`.
Dylan DPC [Tue, 23 Jun 2020 01:16:14 +0000 (03:16 +0200)]
Rollup merge of #71756 - carstenandrich:master, r=dtolnay
add Windows system error codes that should map to io::ErrorKind::TimedOut
closes #71646
**Disclaimer:** The author of this pull request has a negligible amount of experience (i.e., kinda zero) with the Windows API. This PR should _definitely_ be reviewed by someone familiar with the API and its error handling.
While porting POSIX software using serial ports to Windows, I found that for many Windows system error codes, an `io::Error` created via `io::Error::from_raw_os_error()` or `io::Error::last_os_error()` is not `io::ErrorKind::TimedOut`. For example, when a (non-overlapped) write to a COM port via [`WriteFile()`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile) times out, [`GetLastError()`](https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror) returns `ERROR_SEM_TIMEOUT` ([121](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)). However, an `io::Error` created from this error code will have `io::ErrorKind::Other`.
Currently, only the error codes `ERROR_OPERATION_ABORTED` and `WSAETIMEDOUT` will instantiate `io::Error`s with kind `io::ErrorKind::TimedOut`.
This makes `io::Error::last_os_error()` unsuitable for error handling of syscalls that could time out, because timeouts can not be caught by matching the error's kind against `io::ErrorKind::TimedOut`.
Downloading the [list of Windows system error codes](https://gist.github.com/carstenandrich/c331d557520b8a0e7f44689ca257f805) and grepping anything that sounds like a timeout (`egrep -i "timed?.?(out|limit)"`), I've identified the following error codes that should also have `io::ErrorKind::TimedOut`, because they could be I/O-related:
Name | Code | Description
--- | --- | ---
`ERROR_SEM_TIMEOUT` | [121](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-) | The semaphore timeout period has expired.
`WAIT_TIMEOUT` | [258](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-) | The wait operation timed out.
`ERROR_DRIVER_CANCEL_TIMEOUT` | [594](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--500-999-) | The driver %hs failed to complete a cancelled I/O request in the allotted time.
`ERROR_COUNTER_TIMEOUT` | [1121](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1000-1299-) | A serial I/O operation completed because the timeout period expired. The IOCTL_SERIAL_XOFF_COUNTER did not reach zero.)
`ERROR_TIMEOUT` | [1460](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1300-1699-) | This operation returned because the timeout period expired.
`ERROR_CTX_MODEM_RESPONSE_TIMEOUT` | [7012](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--6000-8199-) | The modem did not respond to the command sent to it. Verify that the modem is properly cabled and powered on.
`ERROR_CTX_CLIENT_QUERY_TIMEOUT` | [7040](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--6000-8199-) | The client failed to respond to the server connect message.
`ERROR_DS_TIMELIMIT_EXCEEDED` | [8226](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--8200-8999-) | The time limit for this request was exceeded.
`DNS_ERROR_RECORD_TIMED_OUT` | [9705](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--9000-11999-) | DNS record timed out.
`ERROR_IPSEC_IKE_TIMED_OUT` | [13805](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--12000-15999-) | Negotiation timed out.
The following errors are also timeouts, but they don't seem to be directly related to I/O or network operations:
Name | Code | Description
--- | --- | ---
`ERROR_SERVICE_REQUEST_TIMEOUT` | [1053](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1000-1299-) | The service did not respond to the start or control request in a timely fashion.
`ERROR_RESOURCE_CALL_TIMED_OUT` | [5910](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--4000-5999-) | The call to the cluster resource DLL timed out.
`FRS_ERR_SYSVOL_POPULATE_TIMEOUT` | [8014](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--6000-8199-) | The file replication service cannot populate the system volume because of an internal timeout. The event log may have more information.
`ERROR_RUNLEVEL_SWITCH_TIMEOUT` | [15402](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--12000-15999-) | The requested run level switch cannot be completed successfully since one or more services will not stop or restart within the specified timeout.
`ERROR_RUNLEVEL_SWITCH_AGENT_TIMEOUT` | [15403](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--12000-15999-) | A run level switch agent did not respond within the specified timeout.
Please note that `ERROR_SEM_TIMEOUT` is the only timeout error I have [seen in action](https://gist.github.com/carstenandrich/10b3962fa1abc9e50816b6460010900b). The remainder of the error codes listed above is based purely on reading documentation.
This pull request adds all of the errors listed in both tables, but I'm not sure whether adding all of them makes sense. Someone with actual Windows API experience should decide that.
I expect these changes to be fairly backwards compatible, because only the error's [`.kind()`](https://doc.rust-lang.org/std/io/struct.Error.html#method.kind) will change, but matching the error's code via [`.raw_os_error()`](https://doc.rust-lang.org/std/io/struct.Error.html#method.raw_os_error) will not be affected.
However, code expecting these errors to be `io::ErrorKind::Other` would break. Even though I personally do not think such an implementation would make sense, after all the docs say that `io::ErrorKind` is _intended to grow over time_, a residual risk remains, of course. I took the liberty to ammend the docstring of `io::ErrorKind::Other` with a remark that discourages matching against it.
As per the contributing guidelines I'm adding @steveklabnik due to the changed documentation. Also @retep998 might have some valuable insights on the error codes.
bors [Tue, 23 Jun 2020 00:13:50 +0000 (00:13 +0000)]
Auto merge of #73007 - yoshuawuyts:socketaddr-from-string-u16, r=sfackler
impl ToSocketAddrs for (String, u16)
This adds a convenience impl of `ToSocketAddrs for (String, u16)`. When authoring HTTP services it's common to take command line options for `host` and `port` and parse them into `String` and `u16` respectively. Consider the following program:
```rust
#[derive(Debug, StructOpt)]
struct Config {
host: String,
port: u16,
}
async fn main() -> io::Result<()> {
let config = Config::from_args();
let stream = TcpStream::connect((&*config.host, config.port))?; // &* is not ideal
// ...
}
```
Networking is a pretty common starting point for people new to Rust, and seeing `&*` in basic examples can be confusing. Even as someone that has experience with networking in Rust I tend to forget that `String` can't be passed directly there. Instead with this patch we can omit the `&*` conversion and pass `host` directly:
```rust
#[derive(Debug, StructOpt)]
struct Config {
host: String,
port: u16,
}
async fn main() -> io::Result<()> {
let config = Config::from_args();
let stream = TcpStream::connect((config.host, config.port))?; // no more conversions!
// ...
}
```
I think should be an easy and small ergonomics improvement for networking. Thanks!
Niko Matsakis [Mon, 8 Jun 2020 23:12:01 +0000 (23:12 +0000)]
fix subtle bug in NLL type checker
The bug was revealed by the behavior of the old-lub-glb-hr-noteq1.rs
test. The old-lub-glb-hr-noteq2 test shows the current 'order dependent'
behavior of coercions around higher-ranked functions, at least when
running with `-Zborrowck=mir`.
Aaron Hill [Mon, 22 Jun 2020 17:29:04 +0000 (13:29 -0400)]
Stop using old version of `syn` in `rustc-workspace-hack`
None of the tools seem to need syn 0.15.35, so we can just build syn
1.0.
This was causing an issue with clippy's `compile-test` program: since
multiple versions of `syn` would exist in the build directory, we would
non-deterministically pick one based on filesystem iteration order. If
the pre-1.0 version of `syn` was picked, a strange build error would
occur (see
https://github.com/rust-lang/rust/pull/73594#issuecomment-647671463)
To prevent this kind of issue from happening again, we now panic if we
find multiple versions of a crate in the build directly, instead of
silently picking the first version we find.
bors [Mon, 22 Jun 2020 16:38:21 +0000 (16:38 +0000)]
Auto merge of #73415 - ehuss:update-cargo, r=ehuss
Update cargo
3 commits in 79c769c3d7b4c2cf6a93781575b7f592ef974255..089cbb80b73ba242efdcf5430e89f63fa3b5328d
2020-06-11 22:13:37 +0000 to 2020-06-15 14:38:34 +0000
- Support linker with -Zdoctest-xcompile. (rust-lang/cargo#8359)
- Fix doctests not running with --target=HOST. (rust-lang/cargo#8358)
- Allow passing a registry index url directly to `cargo install` (rust-lang/cargo#8344)
Niko Matsakis [Wed, 20 May 2020 14:31:51 +0000 (14:31 +0000)]
upcasting traits requires only that things become more general
Revert the code that states that upcasting traits requires full
equality and change to require that the source type is a subtype of
the target type, as one would expect. As the comment states, this was
an old bug that we didn't want to fix yet as it interacted poorly with
the old leak-check. This fixes the old-lub-glb-object test, which was
previously reporting too many errors (i.e., in the previous commit).
Niko Matsakis [Wed, 20 May 2020 10:19:36 +0000 (10:19 +0000)]
move leak-check to during coherence, candidate eval
In particular, it no longer occurs during the subtyping check. This is
important for enabling lazy normalization, because the subtyping check
will be producing sub-obligations that could affect its results.
Consider an example like
for<'a> fn(<&'a as Mirror>::Item) =
fn(&'b u8)
where `<T as Mirror>::Item = T` for all `T`. We will wish to produce a
new subobligation like
<'!1 as Mirror>::Item = &'b u8
This will, after being solved, ultimately yield a constraint that `'!1
= 'b` which will fail. But with the leak-check being performed on
subtyping, there is no opportunity to normalize `<'!1 as
Mirror>::Item` (unless we invoke that normalization directly from
within subtyping, and I would prefer that subtyping and unification
are distinct operations rather than part of the trait solving stack).
The reason to keep the leak check during coherence and trait
evaluation is partly for backwards compatibility. The coherence change
permits impls for `fn(T)` and `fn(&T)` to co-exist, and the trait
evaluation change means that we can distinguish those two cases
without ambiguity errors. It also avoids recreating #57639, where we
were incorrectly choosing a where clause that would have failed the
leak check over the impl which succeeds.
The other reason to keep the leak check in those places is that I
think it is actually close to the model we want. To the point, I think
the trait solver ought to have the job of "breaking down"
higher-ranked region obligation like ``!1: '2` into into region
obligations that operate on things in the root universe, at which
point they should be handed off to polonius. The leak check isn't
*really* doing that -- these obligations are still handed to the
region solver to process -- but if/when we do adopt that model, the
decision to pass/fail would be happening in roughly this part of the
code.
This change had somewhat more side-effects than I anticipated. It
seems like there are cases where the leak-check was not being enforced
during method proving and trait selection. I haven't quite tracked
this down but I think it ought to be documented, so that we know what
precisely we are committing to.
One surprising test was `issue-30786.rs`. The behavior there seems a
bit "fishy" to me, but the problem is not related to the leak check
change as far as I can tell, but more to do with the closure signature
inference code and perhaps the associated type projection, which
together seem to be conspiring to produce an unexpected
signature. Nonetheless, it is an example of where changing the
leak-check can have some unexpected consequences: we're now failing to
resolve a method earlier than we were, which suggests we might change
some method resolutions that would have been ambiguous to be
successful.
TODO:
* figure out remainig test failures
* add new coherence tests for the patterns we ARE disallowing
Niko Matsakis [Tue, 19 May 2020 01:09:40 +0000 (01:09 +0000)]
rewrite leak check to be based on universes
In the new leak check, instead of getting a list of placeholders to
track, we look for any placeholder that is part of a universe which
was created during the snapshot.
We are looking for the following error patterns:
* P1: P2, where P1 != P2
* P1: R, where R is in some universe that cannot name P1
This new leak check is more precise than before, in that it accepts
this patterns:
* R: P1, even if R cannot name P1, because R = 'static is a valid
sol'n
* R: P1, R: P2, as above
Note that this leak check, when running during subtyping, is less
efficient than before in some sense because it is going to check and
re-check all the universes created since the snapshot. We're going to
move when the leak check runs to try and correct that.
Niko Matsakis [Mon, 18 May 2020 09:43:36 +0000 (09:43 +0000)]
modify leak-check to track only outgoing edges from placeholders
Also, update the affected tests. This seems strictly better but it is
actually more permissive than I initially intended. In particular it
accepts this
Dylan DPC [Mon, 22 Jun 2020 12:53:56 +0000 (14:53 +0200)]
Rollup merge of #73585 - LeSeulArtichaut:patch-3, r=Mark-Simulacrum
Do not send a notification for P-high stable regressions
This is kind of a hack to only match nightly and beta regressions, but not stable regressions. See my tests [on the playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6ff8a809162118aa2951f2ff12400067).
Aaron Hill [Mon, 22 Jun 2020 01:27:34 +0000 (21:27 -0400)]
Fix spurious 'value moved here in previous iteration of loop' messages
Fixes #46099
Previously, we would check the 'move' and 'use' spans to see if we
should emit this message. However, this can give false positives when
macros are involved, since two distinct expressions may end up with the
same span.
Instead, we check the actual MIR `Location`, which eliminates false
positives.
bors [Sun, 21 Jun 2020 21:05:57 +0000 (21:05 +0000)]
Auto merge of #73180 - matthewjasper:predicate-cache, r=nikomatsakis
Cache flags and escaping vars for predicates
With predicates becoming interned (rust-lang/compiler-team#285) this is now possible and could be a perf win. It would become an even larger win once we have recursive predicates.
bors [Sun, 21 Jun 2020 17:10:09 +0000 (17:10 +0000)]
Auto merge of #72936 - jackh726:chalk-more, r=nikomatsakis
Upgrade Chalk
Things done in this PR:
- Upgrade Chalk to `0.11.0`
- Added compare-mode=chalk
- Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk
- Removed `RustDefId` since the builtin type support is there
- Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk
- Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`)
- Lower `RegionOutlives` and `ObjectSafe` predicates
- Lower `Dyn` without the region
- Handle `Int`/`Float` `CanonicalVarKind`s
- Uncomment some Chalk tests that actually work now
- Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different
Dan Aloni [Sat, 13 Jun 2020 17:58:46 +0000 (20:58 +0300)]
Prefer accessible paths in 'use' suggestions
This fixes an issue with the following sample:
mod foo {
mod inaccessible {
pub struct X;
}
pub mod avail {
pub struct X;
}
}
fn main() { X; }
Instead of suggesting both `use crate::foo::inaccessible::X;` and `use
crate::foo::avail::X;`, it should only suggest the latter.
It is done by trimming the list of suggestions from inaccessible paths
if accessible paths are present.
Visibility is checked with `is_accessible_from` now instead of being
hard-coded.
-
Some tests fixes are trivial, and others require a bit more explaining,
here are my comments:
src/test/ui/issues/issue-35675.stderr: Only needs to make the enum
public to have the suggestion make sense.
src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't
help because its constructor is not visible, so the attempted
constructor does not work. In that case, it's better not to suggest it.
The case where the constructor is public is covered in `issue-26545.rs`.
bors [Sun, 21 Jun 2020 13:18:00 +0000 (13:18 +0000)]
Auto merge of #72696 - jethrogb:jb/llvm-zlib, r=Mark-Simulacrum
Enable LLVM zlib
Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error:
`rust-lld: error: ...: contains a compressed section, but zlib is not available`
bors [Sun, 21 Jun 2020 02:20:07 +0000 (02:20 +0000)]
Auto merge of #70946 - jumbatm:clashing-extern-decl, r=nagisa
Add a lint to catch clashing `extern` fn declarations.
Closes #69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
Rollup merge of #73443 - pietroalbini:gha-auto-fallible, r=Mark-Simulacrum
ci: allow gating GHA on everything but macOS
In our GitHub Actions setup macOS is too unreliable to gate on it, but the other builders work fine. This commit splits the macOS builders into a separate job (called `auto-fallible`), allowing us to gate on the auto job without failing due to macOS spurious failures.
cc https://github.com/rust-lang/rust-central-station/issues/848
r? @Mark-Simulacrum
Rollup merge of #73287 - davidtwco:issue-73251-opaque-types-in-projections, r=estebank
lint: normalize projections using opaque types
Fixes #73251.
This PR normalizes projections which use opaque types (opaque types are otherwise linted against, which is would have previously made the test cases added in this PR fail).
Rollup merge of #72790 - jonhoo:duration-is-zero, r=LukasKalbertodt
core/time: Add Duration methods for zero
This patch adds two methods to `Duration`. The first, `Duration::zero`,
provides a `const` constructor for getting an zero-length duration. This
is also what `Default` provides (this was clarified in the docs), though
`default` is not `const`.
The second, `Duration::is_zero`, returns true if a `Duration` spans no
time (i.e., because its components are all zero). Previously, the way to
do this was either to compare both `as_secs` and `subsec_nanos` to 0, to
compare against `Duration::new(0, 0)`, or to use the `u128` method
`as_nanos`, none of which were particularly elegant.
Rollup merge of #72788 - matthewjasper:projection-bound-validation, r=nikomatsakis
Projection bound validation
During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.
However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.
This PR makes 2 fixes for this:
1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.
Rollup merge of #72456 - ldm0:dereftrait, r=estebank
Try to suggest dereferences on trait selection failed
Fixes #39029 Fixes #62530
This PR consists of two parts:
1. Decouple `Autoderef` with `FnCtxt` and move `Autoderef` to `librustc_trait_selection`.
2. Try to suggest dereferences when trait selection failed.
The first is needed because:
1. For suggesting dereferences, the struct `Autoderef` should be used. But before this PR, it is placed in `librustc_typeck`, which depends on `librustc_trait_selection`. But trait selection error emitting happens in `librustc_trait_selection`, if we want to use `Autoderef` in it, dependency loop is inevitable. So I moved the `Autoderef` to `librustc_trait_selection`.
2. Before this PR, `FnCtxt` is coupled to `Autoderef`, and `FnCtxt` only exists in `librustc_typeck`. So decoupling is needed.
After this PR, we can get suggestion like this:
```
error[E0277]: the trait bound `&Baz: Happy` is not satisfied
--> $DIR/trait-suggest-deferences-multiple.rs:34:9
|
LL | fn foo<T>(_: T) where T: Happy {}
| ----- required by this bound in `foo`
...
LL | foo(&baz);
| ^^^^
| |
| the trait `Happy` is not implemented for `&Baz`
| help: consider adding dereference here: `&***baz`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
bors [Sat, 20 Jun 2020 19:14:52 +0000 (19:14 +0000)]
Auto merge of #73550 - RalfJung:rollup-5huj1k1, r=RalfJung
Rollup of 9 pull requests
Successful merges:
- #72600 (Properly encode AnonConst into crate metadata)
- #73055 (remove leftover mentions of `skol` and `int` from the compiler)
- #73058 (Support sanitizers on aarch64-unknown-linux-gnu)
- #73171 (RISC-V Emulated Testing)
- #73404 (Update CFGuard syntax)
- #73444 (ci: disable alt build during try builds)
- #73471 (Prevent attacker from manipulating FPU tag word used in SGX enclave)
- #73539 (Deprecate `Vec::remove_item`)
- #73543 (Clean up E0695 explanation)
projects / rust.git / log