Implement constructor tearoffs support in Cider

[eernstg]

This issue tracks support of the constructor tearoffs feature. See the enclosing meta-issue for details.

[devoncarew]

@keertip - do you know if there's work to do here? Can you test this out?

[keertip]

Sorry, missed this. Looks like there is a bit of work to be done here, with regards to sdk version and cider.

[devoncarew]

Thanks for the investigation!

It sounds like - from an IM chat - that we'll hit this every time an experimental flag flips to default to true. Is this something we could automate? I believe that the Cider analysis server impl has its own set of flags to enable; could this instead use the list of sdk default flags? cc @scheglov

[scheglov]

Don't know yet about Cider specifically, but found that for analysis in Bazel we have 2.14 hard-coded.

_version_null_safety = "2.14"
_version_for_analyzer = _version_null_safety

[scheglov]

When running from sources, constructor-tearoffs seems to work.
But when using the prod version of Cider - not.
So, we might need to wait until it percolates to prod.

[getFileForPath][path: third_party/dart/analyzer/lib/src/util/glob.dart][featureSet: FeatureSet{constant-update-2018, constructor-tearoffs, control-flow-collections, extension-methods, generic-metadata, non-nullable, nonfunction-type-aliases, set-literals, spread-collections, triple-shift}][packageLanguageVersion: 2.15.0]

[keertip]

@scheglov , if constructor tear off is used in a package where null safety has been enabled in the build file, then it works fine.

But if it is used in a package which is not null safe, then I see the message This requires the 'constructor-tearoffs' language feature to be enabled.

It does look like the version we are returning in Cider for indicating null safety is not enabled interferes with other language features being enabled.

[bwilkerson]

That's by design. Language features are tied to versions of the SDK, and enabling a later version of an SDK enables all of the language features in earlier versions. This ensures that the implementors aren't required to support a combinatorial explosion of different versions of the language.

The effect of that is that users can't enable constructor tear-offs without also enabling null safety.

[devoncarew]

Gotcha, thanks. It sounds like the work for Cider has been done. We should likely (separately) clarify / raise awareness that not moving to null safety will inhibit adoption of subsequent language features.

[keertip]

Thanks for the explanation Brian. Good to know it's working as intended.