Refer to types using the local identifier #44642

estebank · 2017-09-17T00:41:31Z

On type errors, refer to types using the locally available name when
they have been imported into scope instead of the fully qualified path.

error[E0308]: mismatched types
 --> file.rs:7:24
  |
7 |     let y: Option<X> = Ok(());
  |                        ^^^^^^ expected enum `std::option::Option`, found enum `std::result::Result`
  |
  = note: expected type `Option<X>`
             found type `Result<(), _>`
  = help: here are some functions which might fulfill your needs:
          - .err()
          - .unwrap_err()

Re: #21934.

rust-highfive · 2017-09-17T00:41:42Z

r? @nikomatsakis

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

bors · 2017-09-17T05:24:20Z

☔ The latest upstream changes (presumably #44634) made this pull request unmergeable. Please resolve the merge conflicts.

On type errors, refer to types using the locally available name when they have been imported into scope instead of the fully qualified path. ``` error[E0308]: mismatched types --> file.rs:7:24 | 7 | let y: Option<X> = Ok(()); | ^^^^^^ expected enum `std::option::Option`, found enum `std::result::Result` | = note: expected type `Option<X>` found type `Result<(), _>` = help: here are some functions which might fulfill your needs: - .err() - .unwrap_err() ```

arielb1 · 2017-09-17T08:54:19Z

src/librustc/ty/context.rs

@@ -1179,6 +1179,10 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> {
        self.all_crate_nums(LOCAL_CRATE)
    }

+    pub fn cstore(&self) -> &CrateStore {


I think @alexcrichton removed this for a reason.

I'm sure. This was a quick fix after rebasing against master to get the code as I had written it working. I fully intend to clean this up before attempting to merge this PR.

arielb1 · 2017-09-17T10:47:05Z

src/librustc/infer/error_reporting/mod.rs

@@ -357,7 +359,7 @@ impl<'a, 'gcx, 'tcx> InferCtxt<'a, 'gcx, 'tcx> {
                // for imported and non-imported crates
                if exp_path == found_path
                || exp_abs_path == found_abs_path {
-                    let crate_name = self.tcx.crate_name(did1.krate);
+                    let crate_name = self.tcx.cstore().crate_name_untracked(did1.krate);


Why can't you use crate_name here?

This is a spurious change that should not have happened. I introduced it after hastily rebasing to HEAD of master when the moving of cstore from sess to tcx happened. I'll revert.

arielb1 · 2017-09-17T10:49:12Z

src/librustc/infer/error_reporting/mod.rs

+    full_imports: FxHashMap<String, String>,
+}
+
+impl<'a, 'gcx, 'tcx> ImportVisitor<'a, 'gcx, 'tcx> {


This looks likely to be buggy - you are reimplementing half of name resolution. Could name resolution be made to supply a types_in_scope map?

cc @jseyfried - is there a way for resolution to be called after it is complete?

I figured that was the case, but it was the closest I've been in any of my approaches to get this working. Once I saw that the suggestion machinery used a visitor it gave me enough context to get this. Having this also allowed me to identify the unit tests that would need to change. It is definitely less than ideal and fully expect there to be a way to do this using existing datastructures, but I feel it is much easier for me to point at this code and saw "this is what I want to do, is there a better way?". :)

There's not a way to do name resolution after lowering to HIR (i.e. after we drop the Resolver). A naive solution would be to keep the Resolver for longer, but that would hog memory and isn't ideal since the Resolver has needless complexity used for import resolution and is based on the AST.

@nikomatsakis and I have discussed creating and saving some name resolution structures for this purpose before destroying the Resolver, but we haven't made detailed designs.

arielb1 · 2017-09-17T10:54:54Z

src/librustc/infer/error_reporting/mod.rs

+struct ImportVisitor<'a, 'gcx: 'a + 'tcx, 'tcx: 'a> {
+    tcx: TyCtxt<'a, 'gcx, 'tcx>,
+    /// All the `Item`s from other scopes visible from this `TyCtxt`, as well as their local name.
+    full_imports: FxHashMap<String, String>,


Why not an FxHashMap<DefId, String>?

This is an artifact from the exploratory way I wrote this code, as while working on this I didn't have access to DefIds from other crates. Very sensible suggestion.

arielb1 · 2017-09-17T11:01:31Z

src/librustc/infer/error_reporting/mod.rs

+    }
+}
+
+/// This struct knows how to print out a single type for human consumption, compare two types and


Can this replace rustc::util::ppaux?

That is my eventual objective. I have moved the type argument elision code away from TyCtxt in order to isolate as much from it as possible in order to unify it with the code in ppaux. Do you think I should strive to do it in this PR?

arielb1 · 2017-09-17T11:02:45Z

src/librustc/infer/error_reporting/mod.rs

+                s.push_str(&self.ty_str(ty_and_mut.ty));
+                s
+            }
+            _ => format!("{}", ty),


You really want to replace the entirety of ppaux here. Otherwise e.g. everything within a trait object will go back to ugly.

Yes, that is indeed true. Given how big this PR was getting I thought that it was a good idea to put it out there to get feedback before going further down this rabbit hole. That being said, this covered a big enough percentage of cases that allowed me to test this approach.

alexcrichton · 2017-09-17T16:14:42Z

src/librustc/infer/error_reporting/mod.rs

+                        }
+                    } else {
+                        // Importing from a different crate.
+                        for child in self.tcx.cstore().item_children_untracked(def_id,


Ah so the "untracked" here means that it's not tracked by incremental compilation, so this is something that we're going to want to handle as this is all happening after the tcx is created. If you need help turning this into a query though just let me know!

Could you point me in the right direction of a query being performed? I haven't worked in that part of the compiler yet and would appreciate having a thread to pull from to unravel that sweater.

Sure! You can check out #41417 for some more info

estebank

TL;DR: Some of the weird code is the result of hastily rebasing against master and pushing the code out without reworking it to fit the current state of the compiler, and some is the result of the exploratory way I was writing the code without going back to clean it up after the reasons for the current state were no longer there.

estebank · 2017-09-17T18:36:17Z

src/librustc/infer/error_reporting/mod.rs

@@ -357,7 +359,7 @@ impl<'a, 'gcx, 'tcx> InferCtxt<'a, 'gcx, 'tcx> {
                // for imported and non-imported crates
                if exp_path == found_path
                || exp_abs_path == found_abs_path {
-                    let crate_name = self.tcx.crate_name(did1.krate);
+                    let crate_name = self.tcx.cstore().crate_name_untracked(did1.krate);


This is a spurious change that should not have happened. I introduced it after hastily rebasing to HEAD of master when the moving of cstore from sess to tcx happened. I'll revert.

estebank · 2017-09-17T18:37:24Z

src/librustc/infer/error_reporting/mod.rs

+struct ImportVisitor<'a, 'gcx: 'a + 'tcx, 'tcx: 'a> {
+    tcx: TyCtxt<'a, 'gcx, 'tcx>,
+    /// All the `Item`s from other scopes visible from this `TyCtxt`, as well as their local name.
+    full_imports: FxHashMap<String, String>,


This is an artifact from the exploratory way I wrote this code, as while working on this I didn't have access to DefIds from other crates. Very sensible suggestion.

estebank · 2017-09-17T18:39:30Z

src/librustc/infer/error_reporting/mod.rs

+    }
+}
+
+/// This struct knows how to print out a single type for human consumption, compare two types and


That is my eventual objective. I have moved the type argument elision code away from TyCtxt in order to isolate as much from it as possible in order to unify it with the code in ppaux. Do you think I should strive to do it in this PR?

estebank · 2017-09-17T18:41:14Z

src/librustc/infer/error_reporting/mod.rs

+                s.push_str(&self.ty_str(ty_and_mut.ty));
+                s
+            }
+            _ => format!("{}", ty),


Yes, that is indeed true. Given how big this PR was getting I thought that it was a good idea to put it out there to get feedback before going further down this rabbit hole. That being said, this covered a big enough percentage of cases that allowed me to test this approach.

estebank · 2017-09-17T18:42:22Z

src/librustc/ty/context.rs

@@ -1179,6 +1179,10 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> {
        self.all_crate_nums(LOCAL_CRATE)
    }

+    pub fn cstore(&self) -> &CrateStore {


I'm sure. This was a quick fix after rebasing against master to get the code as I had written it working. I fully intend to clean this up before attempting to merge this PR.

estebank · 2017-09-17T18:45:00Z

src/test/ui/local-ident.stderr

+  --> $DIR/local-ident.rs:16:28
+   |
+16 |     let y: Option<usize> = Ok(2);
+   |                            ^^^^^ expected enum `std::option::Option`, found enum `std::result::Result`


This is an open question: Do we want to show the fully qualified path here? I don't think length is as much of an issue here as this label doesn't print the type arguments, keeping the line relatively short. Alternatively it might be jarring to have two different things being shown here...

estebank · 2017-09-17T18:46:59Z

src/test/ui/local-ident.stderr

+   |                            ^^^^^ expected enum `std::option::Option`, found enum `std::result::Result`
+   |
+   = note: expected type `Option<usize>`
+              found type `Result<{integer}, _>`


Should we add a note here stating Option: std::option::Option and Result: std::result::Result? This could become a very long list for cases like the one put forward in #40186.

estebank · 2017-09-17T18:49:46Z

src/librustc/infer/error_reporting/mod.rs

+                        }
+                    } else {
+                        // Importing from a different crate.
+                        for child in self.tcx.cstore().item_children_untracked(def_id,


Could you point me in the right direction of a query being performed? I haven't worked in that part of the compiler yet and would appreciate having a thread to pull from to unravel that sweater.

estebank · 2017-09-17T18:53:25Z

src/librustc/infer/error_reporting/mod.rs

+    full_imports: FxHashMap<String, String>,
+}
+
+impl<'a, 'gcx, 'tcx> ImportVisitor<'a, 'gcx, 'tcx> {


I figured that was the case, but it was the closest I've been in any of my approaches to get this working. Once I saw that the suggestion machinery used a visitor it gave me enough context to get this. Having this also allowed me to identify the unit tests that would need to change. It is definitely less than ideal and fully expect there to be a way to do this using existing datastructures, but I feel it is much easier for me to point at this code and saw "this is what I want to do, is there a better way?". :)

krdln · 2017-09-17T20:10:02Z

What about shadowing? For example:

struct Result;

fn main() {
    let res: Result = Ok(());
}

This PR produces the following note:

   = note: expected type `Result`
              found type `Result<(), _>`

(the full path for std::result::Result is present in the former part of the error message though)

alexcrichton · 2017-09-21T16:46:23Z

ping @estebank just want to make sure this doesn't fall off your radar!

nikomatsakis · 2017-09-21T19:16:57Z

r? @arielb1

Reassigning to @arielb1 since he did initial review.

arielb1 · 2017-09-24T13:43:39Z

Still waiting on resolution coordination with @jseyfried.

aidanhs · 2017-10-05T18:58:15Z

Not clear what the status here is - is there an issue that triagers can visit to see progress of any blockers? Just wondering who's 'responsible' for pushing this along :)

bors · 2017-10-07T02:58:48Z

☔ The latest upstream changes (presumably #44614) made this pull request unmergeable. Please resolve the merge conflicts.

aidanhs · 2017-10-12T15:28:03Z

@arielb1 / @jseyfried / @estebank - can anyone clarify what/who this PR is waiting on at the moment (aside from a rebase)? I'm not sure how to triage this at the moment as I don't know what's blocking or if there's an issue we can track!

estebank · 2017-10-12T16:55:53Z

@aidanhs I need to rework the PR to use queries, but I haven't had time available to do so. If people prefer, I can close this PR and resubmit once I've reworked it.

aidanhs · 2017-10-12T20:41:45Z

@estebank ok great, thanks for clarifying! If you reckon you might get to this in the next couple of weeks then I'd be fine with keeping it open - up to you.

alexcrichton · 2017-10-19T14:46:02Z

Here for triage again! I'm going to go ahead and close this now to help clear out the queue, but @estebank of course feel free to resubmit once it's reworked!

rust-highfive assigned nikomatsakis Sep 17, 2017

estebank force-pushed the local-alias branch 6 times, most recently from c28a79a to 154d971 Compare September 17, 2017 01:45

estebank force-pushed the local-alias branch from 154d971 to 01cbfca Compare September 17, 2017 06:56

estebank added 4 commits September 16, 2017 23:56

Fix docstring typo

71b82c4

Move ty printing/elision logic to its own struct

78ccfd6

Add Debug to DiagnosticStyledString

2efc1f8

estebank force-pushed the local-alias branch from 01cbfca to 6877688 Compare September 17, 2017 07:01

arielb1 reviewed Sep 17, 2017

View reviewed changes

alexcrichton reviewed Sep 17, 2017

View reviewed changes

estebank commented Sep 17, 2017

View reviewed changes

carols10cents added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 18, 2017

rust-highfive assigned arielb1 and unassigned nikomatsakis Sep 21, 2017

alexcrichton closed this Oct 19, 2017

Refer to types using the local identifier #44642

Refer to types using the local identifier #44642

Conversation

estebank commented Sep 17, 2017 • edited Loading

rust-highfive commented Sep 17, 2017

bors commented Sep 17, 2017

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

arielb1 Sep 17, 2017 • edited Loading

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

estebank left a 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

Choose a reason for hiding this comment

krdln commented Sep 17, 2017

alexcrichton commented Sep 21, 2017

nikomatsakis commented Sep 21, 2017

arielb1 commented Sep 24, 2017

aidanhs commented Oct 5, 2017

bors commented Oct 7, 2017

aidanhs commented Oct 12, 2017

estebank commented Oct 12, 2017

aidanhs commented Oct 12, 2017

alexcrichton commented Oct 19, 2017

estebank commented Sep 17, 2017 •

edited

Loading

arielb1 Sep 17, 2017 •

edited

Loading