[analysis_server] Non-const constructors aren't suggested in a const context

[parlough]

I haven't determined when this regression was introduced, but it can be painful and reduce widget discovery when developing Flutter apps. You often have a list or similar that is declared as const, but might want to add a new widget that has no const constructor. Yes it will result in an error, but with this regression, they won't show up at all, reducing discovery, as well as causing confusion (and requiring extra work) for those who expect the constructor to exist.

void main() {
  const Tree(fruit: [
    App^
    // ^^^ I'd expect Apple to be a completion suggestion here, but it's not since its constructor isn't const.
  ]);
}

class Tree {
  final List<Apple> fruit;
  const Tree({required this.fruit});
}

class Apple {
  Apple();
}

Completion suggestions:

Tested on: 281241e

[bwilkerson]

I'm not saying that you're wrong, but we also get issues requesting that code completion not suggest non-const constructors in a const context.

I think the problem here is that sometimes const means that const is a requirement and sometimes, especially in Flutter code, it means const is preferred when it's possible but can go away if necessary. I'm not sure whether there's a good heuristic we can use to know which is which, but without one we're bound to do the wrong thing part of the time.

[parlough]

Hmm...good point. I suppose it doesn't make too much sense to get recommended non-const constructors for situations like parameter default values.

On the other hand, my initial feeling is that it's also a bit surprising for a possibility to not show up even in those cases. If it does show up and I try the completion, I at least know it exists and why I can't use it there from the resulting diagnostic. If it doesn't show up as a suggestion, I might think the type is removed or not available in the current library scope.