Fix invalid bounds string generation in rustdoc #58894

GuillaumeGomez · 2019-03-03T15:04:51Z

Very weird and I'm not sure this is the best fix around. However, trying to fix it beforehand seems overly complicated compared to the gain (in clean, it wouldn't change anything since we have to return something so that wouldn't work, and in hir, I'm afraid I'd break something else for very little gain).

Also, I wasn't able to make a small code to reproduce the issue. The only way to test is to document crossbeam directly and check the Scope struct...

r? @QuietMisdreavus

QuietMisdreavus · 2019-03-05T17:29:34Z

The bug seems to be introduced when re-exporting the struct (Scope is actually defined in crossbeam_utils), and i bet the PhantomData<&'env mut &'env ()> has something to do with the erroneous bound.

I was able to reproduce the error with the following code:

use std::marker::PhantomData;

pub struct Scope<'env> {
    _marker: PhantomData<&'env mut &'env ()>,
}

A downstream crate that re-exports the Scope struct will create the erroneous bound. I wonder if this is something we should deal with inside the compiler? @rust-lang/compiler Do inferred region bounds somehow make it into a crate's metadata? Rustdoc is seeing an erroneous where 'env: 'env on the above struct, and we're looking for ways to filter that out in the docs.

QuietMisdreavus · 2019-03-18T16:02:33Z

Your test doesn't properly exercise the bug, since it primarily appears when the struct is re-exported. However, i would still like to see input from @rust-lang/compiler in case it can be fixed on their end.

eddyb · 2019-03-18T17:51:17Z

Do inferred region bounds somehow make it into a crate's metadata?

Well... they must be, mustn't they? Otherwise how do you rely on them cross-crate?

It may be possible that in rustdoc you're using predicates_of (which includes inferred_outlives_of) when you want explicit_predicates_of:

rust/src/librustc/ty/query/mod.rs

Lines 136 to 142 in 0f88167

    
                   /// Returns the predicates written explicit by the user. 
        
                   [] fn explicit_predicates_of: ExplicitPredicatesOfItem(DefId) 
        
                       -> Lrc<ty::GenericPredicates<'tcx>>, 
        
                   /// Returns the inferred outlives predicates (e.g., for `struct 
        
                   /// Foo<'a, T> { x: &'a T }`, this would return `T: 'a`). 
        
                   [] fn inferred_outlives_of: InferredOutlivesOf(DefId) -> Lrc<Vec<ty::Predicate<'tcx>>>,

QuietMisdreavus · 2019-03-18T22:18:39Z

Do inferred region bounds somehow make it into a crate's metadata?

Well... they must be, mustn't they? Otherwise how do you rely on them cross-crate?

I was under the assumption that they could be re-calculated from the definition, but i guess not.

It may be possible that in rustdoc you're using predicates_of (which includes inferred_outlives_of) when you want explicit_predicates_of:
rust/src/librustc/ty/query/mod.rs

It looks like we are using predicates_of when cleaning the AST (and inlining items). I feel like switching to explicit_predicates_of would fix both this issue and #56331.

nikomatsakis · 2019-03-19T14:25:23Z

JFYI we could probably screen out 'a: 'a bounds from the inferred bounds list, although it doesn't sound to me like the "right" fix here necessarily -- that would be done by adding a check roughly here to see whether r == outlived_region, I think

Centril · 2019-03-30T13:03:03Z

Ping from triage, @GuillaumeGomez :)

GuillaumeGomez · 2019-03-31T11:57:54Z

It looks like we are using predicates_of when cleaning the AST (and inlining items). I feel like switching to explicit_predicates_of would fix both this issue and #56331.

Well, it panics when I tried to switch so not sure about that... Investigating.

GuillaumeGomez · 2019-03-31T13:33:17Z

I changed a few things around but we now have a new issue: for non local elements, it just doesn't work. Any idea on this @eddyb?

rust-highfive · 2019-03-31T13:49:18Z

The job x86_64-gnu-llvm-6.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.

travis_time:end:22bc8a3c:start=1554039234938787025,finish=1554039310187377572,duration=75248590547
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---

[00:03:30] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:31] tidy error: /checkout/src/test/rustdoc/useless_lifetime_bound.rs: missing trailing newline
[00:03:32] some tidy checks failed
[00:03:32] 
[00:03:32] 
[00:03:32] 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:03:32] 
[00:03:32] 
[00:03:32] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:32] Build completed unsuccessfully in 0:00:47
[00:03:32] Build completed unsuccessfully in 0:00:47
[00:03:32] Makefile:67: recipe for target 'tidy' failed
[00:03:32] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:26400256
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sun Mar 31 13:38:52 UTC 2019
---
travis_time:end:199745e8:start=1554039533390029443,finish=1554039533395503719,duration=5474276
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:024de792
$ 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 --batch -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:0b3e7aae
travis_time:start:0b3e7aae
$ 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:08395634
$ 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 · 2019-03-31T20:11:17Z

I was under the assumption that they could be re-calculated from the definition, but i guess not.

Yeah, the problem is that the definition is sort of lost (part of why rustdoc needs two codepaths for everything...), and only some information of note is kept.

Although specifically in this case, enough information might be there, but it would be a bit of waste to recompute it each time.

GuillaumeGomez · 2019-04-03T20:13:38Z

Fixed the issue!

GuillaumeGomez · 2019-04-03T20:19:06Z

I also added the test from #59033.

GuillaumeGomez · 2019-04-05T19:32:38Z

cc @rust-lang/compiler

estebank · 2019-04-05T21:36:23Z

@bors r+ r? @estebank

bors · 2019-04-05T21:36:24Z

📌 Commit c966c45 has been approved by estebank

@QuietMisdreavus

…nds, r=estebank Fix invalid bounds string generation in rustdoc Fixes rust-lang#58737. Very weird and I'm not sure this is the best fix around. However, trying to fix it beforehand seems overly complicated compared to the gain (in `clean`, it wouldn't change anything since we **have to** return something so that wouldn't work, and in `hir`, I'm afraid I'd break something else for very little gain). Also, I wasn't able to make a small code to reproduce the issue. The only way to test is to document `crossbeam` directly and check the `Scope` struct... r? @QuietMisdreavus

@ghost

Rollup of 6 pull requests Successful merges: - #58894 (Fix invalid bounds string generation in rustdoc) - #59599 (Updated RELEASES.md for 1.34.0) - #59624 (SGX target: Use linker option to avoid code CGU assignment kludge) - #59696 (Remove invalid assertion back::link::from add_upstream_rust_crates().) - #59707 (Add missing tryfrom example) - #59727 (wasi: Use shared API for preopened fds) Failed merges: r? @ghost

eddyb · 2019-04-06T13:21:25Z

src/librustc_typeck/collect.rs

-    let hir_id = tcx.hir().as_local_hir_id(def_id).unwrap();
+    let hir_id = match tcx.hir().as_local_hir_id(def_id) {
+        Some(hir_id) => hir_id,
+        None => return tcx.predicates_of(def_id),


This is another change to rustc_typeck that wasn't explicitly approved (the comment thread doesn't make it clear that a hack was added outside of rustdoc), can we please not do this? I'll create a PR reverting these, but I feel like we have a larger process break issue...

Yes, I didn't see this notification until now, but please ping me elsewhere instead of merging typeck hacks like this.

Not to mention this is wrong for cross-crate items, my expectation was that explicit_predicates_of was available cross-crate.

@estebank ^

I did ping the compiler team so I thought you'd see the notification, my bad.

Talked with Eddy on chat. My bad as the previous seemed to make sense on isolation. I'll defer to Eddy's assessment on typeck code in the future.

@GuillaumeGomez Being notified isn't enough, we need to acknowledge it too.
With @nikomatsakis less active lately (and also on PTO more recently), a bit more care should be taken.

Opened #59789.

I didn't approved the PR nor asked anyone (except the compiler team) to review it. I approve for more care to be taken but I feel like taking the blame for an error I didn't make. :-/

This is a process failure, not your failure! We'll figure out how to prevent such things happening in the future.

@GuillaumeGomez The one at fault here was me, not you, as I approved this change thinking it looked reasonable without being my main area of expertise, I should have deferred to @eddyb's or @nikomatsakis' judgement on this case.

@nikomatsakis

Revert two unapproved changes to rustc_typeck. There was a breakdown in process (#59004 (comment), #58894 (comment)) and two changes were made to `rustc_typeck`'s "collect" queries, for rustdoc, that were neither needed *nor* correct. I'm reverting them here, and will fix up rustdoc *somehow*, if necessary. cc @rust-lang/compiler How do we ensure this doesn't happen again? r? @nikomatsakis or @oli-obk

@nikomatsakis

Revert two unapproved changes to rustc_typeck. There was a breakdown in process (rust-lang#59004 (comment), rust-lang#58894 (comment)) and two changes were made to `rustc_typeck`'s "collect" queries, for rustdoc, that were neither needed *nor* correct. I'm reverting them here, and will fix up rustdoc *somehow*, if necessary. cc @rust-lang/compiler How do we ensure this doesn't happen again? r? @nikomatsakis or @oli-obk

rust-highfive assigned QuietMisdreavus Mar 3, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 3, 2019

GuillaumeGomez force-pushed the invalid-lifetime-bounds branch from 774fb17 to 869ab87 Compare March 5, 2019 18:23

QuietMisdreavus mentioned this pull request Mar 18, 2019

Fix duplicated bounds printing in rustdoc #59033

Merged

sanxiyn added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 20, 2019

Fix invalid bounds string generation in rustdoc

ddd034a

GuillaumeGomez force-pushed the invalid-lifetime-bounds branch from 869ab87 to ddd034a Compare March 31, 2019 13:32

Fix explicit_predicates_of

f6eb09b

Add test from rust-lang#59033

c966c45

rust-highfive assigned estebank and unassigned QuietMisdreavus Apr 5, 2019

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 5, 2019

Centril mentioned this pull request Apr 5, 2019

Rollup of 6 pull requests #59741

Merged

bors merged commit c966c45 into rust-lang:master Apr 6, 2019

GuillaumeGomez deleted the invalid-lifetime-bounds branch April 6, 2019 12:37

eddyb reviewed Apr 6, 2019

View reviewed changes

ollie27 mentioned this pull request Apr 7, 2019

rustdoc: redundant where 'env: 'env #58737

Closed

eddyb mentioned this pull request Apr 8, 2019

Revert two unapproved changes to rustc_typeck. #59789

Merged

GuillaumeGomez mentioned this pull request Apr 8, 2019

Rustdoc support API in rustc #59790

Closed

jyn514 mentioned this pull request Aug 25, 2020

Apply eddyb's comments made in #58894 #59791

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix invalid bounds string generation in rustdoc #58894

Fix invalid bounds string generation in rustdoc #58894

GuillaumeGomez commented Mar 3, 2019 •

edited

Loading

QuietMisdreavus commented Mar 5, 2019

QuietMisdreavus commented Mar 18, 2019

eddyb commented Mar 18, 2019

QuietMisdreavus commented Mar 18, 2019

nikomatsakis commented Mar 19, 2019

Centril commented Mar 30, 2019

GuillaumeGomez commented Mar 31, 2019

GuillaumeGomez commented Mar 31, 2019

rust-highfive commented Mar 31, 2019

eddyb commented Mar 31, 2019

GuillaumeGomez commented Apr 3, 2019

GuillaumeGomez commented Apr 3, 2019

GuillaumeGomez commented Apr 5, 2019

estebank commented Apr 5, 2019

bors commented Apr 5, 2019

eddyb Apr 6, 2019

eddyb Apr 6, 2019

Centril Apr 6, 2019

GuillaumeGomez Apr 7, 2019

estebank Apr 7, 2019

eddyb Apr 8, 2019

eddyb Apr 8, 2019

GuillaumeGomez Apr 8, 2019

oli-obk Apr 8, 2019

estebank Apr 12, 2019

Fix invalid bounds string generation in rustdoc #58894

Fix invalid bounds string generation in rustdoc #58894

Conversation

GuillaumeGomez commented Mar 3, 2019 • edited Loading

QuietMisdreavus commented Mar 5, 2019

QuietMisdreavus commented Mar 18, 2019

eddyb commented Mar 18, 2019

QuietMisdreavus commented Mar 18, 2019

nikomatsakis commented Mar 19, 2019

Centril commented Mar 30, 2019

GuillaumeGomez commented Mar 31, 2019

GuillaumeGomez commented Mar 31, 2019

rust-highfive commented Mar 31, 2019

eddyb commented Mar 31, 2019

GuillaumeGomez commented Apr 3, 2019

GuillaumeGomez commented Apr 3, 2019

GuillaumeGomez commented Apr 5, 2019

estebank commented Apr 5, 2019

bors commented Apr 5, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Mar 3, 2019 •

edited

Loading