Bad autocompletion for type inside import alias when declaring a function inside a class

[stephane-archer]

output.17.33.13.mov

import 'package:image/image.dart' as img;

[bwilkerson]

I'm guessing that you're referring to the suggestion of fun as a completion after img..

Can you provide a small reproduction?

[stephane-archer]

@bwilkerson yes

import 'package:image/image.dart' as img;

class A {
  img.
}

[stephane-archer]

[FMorschel]

Hover when it is detected to be an alias:

Hover int when detected to be a member name:

Hover img without . (same as for int above):

Hover img. (I think it is considering this as a constructor for some reason):

---

Edit

So @bwilkerson I`m not 100% sure this is an auto-complete issue necessarily but actually a parsing error which leads to this. Not sure if we have a tag for that.

[stephane-archer]

I think looking at this particular example img. should suggest things declared inside package:image/image.dart regardless of any parsing error. I don't expect the autocomplete to stop working because I forgot a ;

[bwilkerson]

I agree. We ought to have recovered well enough to be able to have reasonable suggestions there. I haven't had time to look into why completion is failing in this particular case, but I doubt it's because of a missing semicolon.

[FMorschel]

I think looking at this particular example img. should suggest things declared inside package:image/image.dart regardless of any parsing error. I don't expect the autocomplete to stop working because I forgot a ;

@stephane-archer just so I'm clear, I agree. My comment was about it not identifying img as an alias and that would be the reason for the suggestions not showing up.

The parsing needs to identify it as an alias for the auto-completion to work. If you had for example:

import 'package:image/image.dart' as img;

class A {
  void foo(int img) { // I know this naming makes no sense but bear with me
    img.^
  }
}

Inside A.foo, dart considers int img as having a higher priority for this scope so auto-completion would show only methods/proprieties for an int and not things from the import.

The parser does the job of identifying what img means in that scope. That is why I meant this
is actually a parser problem that leads to bad auto-completion.

---

@bwilkerson I'll take a look at this when I have some time too. If I find anything I'll update it here.

[bwilkerson]

Technically, it isn't a parser problem. The parser only verifies that the code conforms to the grammar; it doesn't do any resolution, that's done by the resolver.

But either way, completion should work even when there's incomplete information.

[stephane-archer]

@FMorschel I agree with you. In your example img. should show the int method rather than the definition from 'package:image/image.dart' but in the case of the parser being lost, showing methods for each symbol that can match the identifier is better than showing nothing. In our example the autocomplete is just lost and shows nothing. Heping the autocomplete to not be lost would be great, but a better default behavior might be nice too.
I imagine is easy to get the parser lost because the code is not yet in the correct shape.

[FMorschel]

I was giving this a try yesterday but I'm still unfamiliar with the code. I tried simply replacing the node from a ConstructorDeclaration into a PrefixedIdentifier but then it warned me that wasn't possible because it had to be either a constructor, a method or a field declaration.

The presence of the . always makes it assume that it is a constructor declaration (even if it has static which makes little sense). As a reference, if you have a type name without a field name, it always gives preference to assume that is a field so I could try to assume the same but I'm not sure if that is the best option since currently it assumes the written value is the field name (which wouldn't fix the problem).

This is even a problem when you have a case like:

class C {
  field; // This could be `int` or anything, it would still be the field name
}

And you try to add this:

import '' as self;

class C {
  self.^ field;
}

While the first case it identified field as a field, when you add self. even with the space it identifies it all as a constructor with field being the name. And it only correctly identifies things if you have a name (even though unexisting) after self. like test which is undeclared, it will warn correctly and identify things the right way.

---

So, to sintesize the above:

• It currently always identifies things with . as a constructor;
• It always assumes SimpleIdentifiers to be a field declaration;
• Because of the above, the written is always identified to be the field name;
• I was able to diferenciate with my local WIP branch between actual constructors and import prefixes;
• The VariableDeclarationList(Impl or not) says nothing about the list never being empty but I'm unsure if I've ever seen a case like this. Can you confirm if creating a field with the variable list being empty is valid @bwilkerson? Once I have something working, I'll see about opening a CL so we can discuss anything else needed.