Inconsistent handling of arguments for disposable types

[psfinaki]

This code produces an error only in the second case:

open System.IO

let stream1 = new MemoryStream 42

let capacity = 42
let stream2 = new MemoryStream capacity

Note there is no error if new is unused (there are legitimate warnings though):

We need to decide what to do about that before addressing this ticket - basically either fix the parser or the code fix.

[vzarytovskii]

We should just stop recommending new for disposables.

[psfinaki]

We should just stop recommending new for disposables.

Well this is sort of orthogonal. We may remove the code fix, or the diagnostic together with the code fix, but as long as the syntax in question is allowed, the inconsistency will stay.

[edgarfgp]

@brianrourkeboll Might this also be fixed by #16239 ?

[brianrourkeboll]

@edgarfgp

@brianrourkeboll Might this also be fixed by #16239 ?

That PR just updated the analyzer and code fix for removing unneeded parens so that it does not suggest removing parens in such cases.

The solution I originally wondered about

Is the atomicExprAfterType restriction here actually still needed? Would that suddenly cause more problems like those addressed by #15923? Or could we just replace it with argExpr in the parser for new and inherit and get rid of the inconsistency? Making that change locally seems to work and doesn't seem to cause any immediate problems in this codebase...

is unfortunately a breaking change, as shown by the tests linked in #16239 (comment) (they would no longer compile).

But yes, the problem in @psfinaki's issue here is indeed the same underlying thing.

[brianrourkeboll]

We could probably add an analyzer and code fix that offers to add parentheses in cases like this, though. It would even be relatively straightforward to update the parser to emit a diagnostic specific to this.