Fix ICE when rustdoc encounters certain usages of HRTBs

[Aaron1011]

Fixes #51236

Under certain circumstances, AutoTraitFinder could end up computing a ParamEnv involving two trait predicates that differed only in the region parameters involved. One of these parameters would be a HRTB, while the other would be a normal region parameter.

When this ParamEnv was later passed to SelectionContext, an Ambiguity error would occur, since the erased versions of these predicates would be identical. To solve the issue, we de-duplicate our list of predicates as we build it up. Whenever we encounter two predicates that differ only in their assignment of region parameters (a HRTB vs a normal lifetime parameter), we pick the HRTB. This corresponds to selecting a 'stricter' bound to display in the generated documentation: we're requiring that a particular type works for all possible lifetime parameters if it's going to implement a particular auto trait.

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:12] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:13] tidy error: /checkout/src/librustc/traits/auto_trait.rs:361: line longer than 100 chars
[00:04:13] tidy error: /checkout/src/librustc/traits/auto_trait.rs:419: line longer than 100 chars
[00:04:13] tidy error: /checkout/src/librustc/traits/auto_trait.rs:433: line longer than 100 chars
[00:04:13] tidy error: /checkout/src/librustc/traits/auto_trait.rs:437: line longer than 100 chars
[00:04:14] some tidy checks failed
[00:04:14] 
[00:04:14] 
[00:04:14] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:14] 
[00:04:14] 
[00:04:14] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:14] Build completed unsuccessfully in 0:00:47
[00:04:14] Build completed unsuccessfully in 0:00:47
[00:04:14] make: *** [tidy] Error 1
[00:04:14] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0e26a3ca
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:29e38c96:start=1533235864116438005,finish=1533235864122468000,duration=6029995
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:12e55cb0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:355bcd8a
travis_time:start:355bcd8a
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:17b23443
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[eddyb]

cc @nikomatsakis We should probably rethink/redo this entire module at some point.
My intuition is that we can at least do something much simpler by ignoring lifetimes, and then maybe find a way to somehow recover lifetime requirements?

@bors r+

[bors]

📌 Commit b010d1f has been approved by eddyb

[bors]

⌛ Testing commit b010d1f with merge 5e4ee7b83a050fc6764ba95006998f1b107abc42...

[bors]

💔 Test failed - status-travis

[rust-highfive]

The job i686-gnu-nopt of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:22:26] test string.rs - string::String (line 87) ... ok
[01:22:26] test string.rs - string::String (line 237) ... ok
[01:22:26] test string.rs - string::String (line 263) ... ok

Broadcast message from root@travis-job-1dc12a19-54b5-4b69-ac12-eb94a4c63300
 (unknown) at 11:58 ...
The system is going down for power off NOW!
[01:22:26] 
[01:22:26] Session terminated, terminating shell...make: *** wait: No child processes.  Stop.
[01:22:26] make: *** Waiting for unfinished jobs....
[01:22:26] make: *** wait: No child processes.  Stop.
[01:22:26]  ...terminated.

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 143.
travis_time:start:09a360a6
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[kennytm]

@bors retry travis-ci/travis-ci#4924

[bors]

⌛ Testing commit b010d1f with merge 4b8089d...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 4b8089d to master...

[earthengine]

It looks like solving this issue causes another. See #53420. Or maybe not? Maybe it is just the same issue in another place to ship the same solution?

[Aaron1011]

@earthengine: While the error message is similar, it appears to be a completely different issue. Both rustdoc and rustc make use of SelectionContext (which this PR did not modify). That issue is coming from rustc, not rustdoc.