The Great Generics Generalisation: HIR Followup #51880

varkor · 2018-06-28T21:17:18Z

Addresses the final comments in #48149.

r? @eddyb, but there are a few things I have yet to clean up. Making the PR now to more easily see when things break.

varkor · 2018-06-28T22:45:43Z

src/librustc_typeck/check/mod.rs

+
+                    if let Some(ref data) = segments[index].args {
+                        let lifetime_offset = if infer_lifetimes[&index] {
+                            defs.own_counts().lifetimes


This should be taken out of the loop.

varkor · 2018-07-03T21:25:20Z

src/test/compile-fail/trait-object-vs-lifetime.rs

@@ -25,5 +25,4 @@ fn main() {
    //~| ERROR wrong number of type arguments: expected 1, found 0
    let _: S<'static +, 'static>;
    //~^ ERROR lifetime parameters must be declared prior to type parameters
-    //~| ERROR at least one non-builtin trait is required for an object type


The reason this error is displayed currently is very much dependent on the ad-hoc parameter-separation that currently goes on. Unless it causes more issues, I really don't think it's worth attempting to preserve behaviour here.

varkor · 2018-07-03T23:09:35Z

@eddyb: this is now ready to be reviewed!

alexreg · 2018-07-09T02:08:23Z

@varkor @eddyb has been away for a week or so now... might be away a while longer, just to let you know. :-)

eddyb · 2018-07-13T06:19:10Z

src/librustc_typeck/check/mod.rs

+            })
+            .cloned()
+            .collect();
+        AstConv::prohibit_generics(self, &segs);


Is this the only use of the variable segs? You might want to change prohibit_generics to take an iterator or something. Either way, having a variable here that's not non_generic_segs is confusing.

stokhos · 2018-07-21T04:57:53Z

Ping from triage, @varkor any update on this PR?

src/librustc_typeck/astconv.rs

+            // Provide substitutions for parameters for which (valid) arguments have been provided.
+            |param, arg| {
+                match param.kind {
+                    GenericParamDefKind::Lifetime => match arg {


src/librustc_typeck/check/method/confirm.rs

+            // Provide substitutions for parameters for which (valid) arguments have been provided.
+            |param, arg| {
+                match param.kind {
+                    GenericParamDefKind::Lifetime => match arg {


src/librustc_typeck/check/mod.rs

+        for &PathSeg(def_id, index) in &path_segs {
+            let seg = &segments[index];
+            let generics = self.tcx.generics_of(def_id);
+            // `impl Trait` is treated as a normal generic parameter internally,


src/librustc_typeck/check/mod.rs

+                if let Some(&PathSeg(_, index)) = path_segs.iter().find(|&PathSeg(did, _)| {
+                    *did == def_id
+                }) {
+                    // If we've encountered an `impl Trait`-related error, we're just


src/librustc_typeck/check/mod.rs

-                            fn_segment.is_some() as usize;
-        AstConv::prohibit_generics(self, &segments[..segments.len() - poly_segments]);
+
+        let mut generic_segs = HashSet::new();


src/librustc_typeck/check/mod.rs

-                }
-            }
-            infer_types_type_seg = seg.infer_types;
+        let mut suppress_errors = FxHashMap();


src/librustc_typeck/check/mod.rs

+                }) {
+                    // If we've encountered an `impl Trait`-related error, we're just
+                    // going to infer the arguments for better error messages.
+                    if !suppress_errors[&index] {


src/librustc_typeck/check/mod.rs

+            },
+            // Provide substitutions for parameters for which (valid) arguments have been provided.
+            |param, arg| {
+                match param.kind {


eddyb · 2018-08-20T03:30:36Z

src/test/ui/bad/bad-mid-path-type-params.stderr

   |
 LL |     let _ = S::new::<isize,f64>(1, 1.0);
-   |                            ^^^ expected 1 type parameter
+   |             ^^^^^^^^^^^^^^^^^^^ unexpected type argument


Hmm, this seems to have regressed, could you somehow use each GenericArg's individual span?

eddyb · 2018-08-20T03:30:53Z

src/test/ui/bad/bad-mid-path-type-params.stderr

   |
 LL |     let _: S2 = Trait::<'a,isize>::new::<f64>(1, 1.0);
-   |                         ^^ expected 0 lifetime parameters
+   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unexpected lifetime argument


Similar situation here.

eddyb · 2018-08-20T03:37:37Z

Overall I'm really happy with the progress made here! 🎉
The main issue I see before merging this is the diagnostics regression.
Other than that, I won't block this PR on fusing checking and building substs.

eddyb · 2018-08-20T12:21:19Z

src/librustc_typeck/astconv.rs

@@ -255,9 +256,9 @@ impl<'o, 'gcx: 'tcx, 'tcx> dyn AstConv<'gcx, 'tcx>+'o {
                &empty_args
            },
            if is_method_call {
-                GenericArgPosition::Method
+                GenericArgPosition::Associated


Okay I was wrong, if it's for the method call syntax, i.e. not Trait::method, then it should called MethodCall.

eddyb · 2018-08-20T15:07:49Z

src/test/ui/unboxed-closures/unboxed-closure-sugar-wrong-trait.stderr

   |
 LL | fn f<F:Trait(isize) -> isize>(x: F) {}
-   |        ^^^^^^^^^^^^^^^^^^^^^ expected no type arguments
+   |             ^^^^^^^^^^^^^^^^ unexpected type argument


Hmm this span seems wrong, it should end at the ), I wonder if that's a bug in how T(A) -> R turns into T<(A,), Output = R>.

Yeah, this one looked a little weird to me, but I thought it was probably due to function syntax issues that weren't related to this change.

Open an issue so we can maybe clean this up in the future.

Opened #53534.

eddyb · 2018-08-20T15:08:20Z

src/test/ui/typeck/typeck_type_placeholder_lifetime_2.stderr

   |
 LL |     let c: Foo<_, usize> = Foo { r: &5 };
-   |            ^^^^^^^^^^^^^ expected 1 type argument
+   |                   ^^^^^ unexpected type argument


Nice improvement!

eddyb · 2018-08-20T15:43:42Z

@bors r+ p=42 (we don't want this to bitrot)

bors · 2018-08-20T15:44:26Z

📌 Commit ee9bd0f has been approved by eddyb

bors · 2018-08-20T15:47:47Z

⌛ Testing commit ee9bd0f with merge 1558ae7...

@eddyb

…=eddyb The Great Generics Generalisation: HIR Followup Addresses the final comments in #48149. r? @eddyb, but there are a few things I have yet to clean up. Making the PR now to more easily see when things break. cc @yodaldevoid

bors · 2018-08-20T18:26:18Z

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

src/test/ui/generic/generic-impl-more-params-with-defaults.stderr

rust-highfive assigned eddyb Jun 28, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 28, 2018

This comment has been minimized.

Sign in to view

varkor force-pushed the generics-hir-generalisation-followup branch from 8b45e20 to f82e51f Compare June 28, 2018 21:57

This comment has been minimized.

Sign in to view

varkor commented Jun 28, 2018

View reviewed changes

est31 mentioned this pull request Jun 29, 2018

Tracking issue for const generics (RFC 2000) #44580

Closed

16 tasks

varkor force-pushed the generics-hir-generalisation-followup branch 2 times, most recently from 5af5a59 to e72e03d Compare June 29, 2018 22:42

This comment has been minimized.

Sign in to view

varkor force-pushed the generics-hir-generalisation-followup branch from e72e03d to 0d23eef Compare July 2, 2018 00:18

This comment has been minimized.

Sign in to view

varkor force-pushed the generics-hir-generalisation-followup branch 3 times, most recently from 493fcd4 to 0abb1c5 Compare July 2, 2018 17:24

This comment has been minimized.

Sign in to view

varkor commented Jul 3, 2018

View reviewed changes

varkor changed the title ~~[WIP] The Great Generics Generalisation: HIR Followup~~ The Great Generics Generalisation: HIR Followup Jul 3, 2018

eddyb reviewed Jul 13, 2018

View reviewed changes

stokhos 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 Jul 21, 2018