Drawbacks:
* Only covers cases where the invocation is nested within an executable statement
* Performs abysmally due to creating a whole speculative semantic model for the vast majority of invocations, and additionally using GetOperation which is quite slow in general

At some point amongst all the code that runs there is presumably a crucial function which has the rules for binding a name-type syntax into an invocation.
Ideally we'd find a way to call just that function here on invocationExpression.Expression

(even without an arg list)

It's possible there are some other cases when VB will happily invoke something without an arg list, but since i can't find the relevant spec or code, I'm erring on the side of caution

…ionTests.vb

Co-Authored-By: CyrusNajmabadi <cyrus.najmabadi@gmail.com>

Therefore we can't know it's safe to remove parentheses since it could be a delegate

This is to allow "TestInsertCallIfNecessary3()" to continue to pass.
Note that the test result isn't fully simplified since it says:
Call (Sub() Exit Sub)
instead of
Call Sub() Exit Sub
This is outside the scope of this PR

There is no parameterless Console.Write hence it doesn't resolve, and Program doesn't exist in the context at all
Don't think it's worth considering CandidateSymbols since they won't always be correct

Expanding and reducing stuff that doesn't compile sounds generally risky. In a future PR perhaps the expander shouldn't add the parentheses if it can't resolve the symbol.

If it wasn't invokable it wouldn't be valid at this point

This reverts commit 3787058.

…ach method

…rmed" XML comments contain superfluous /// markers for every line-break in the original comment.

…clarationNameCompletionProvider.NameGenerator.cs

Co-Authored-By: CyrusNajmabadi <cyrus.najmabadi@gmail.com>

…king if the first character is a digit.

…clarationNameCompletionProvider.NameGenerator.cs

Co-Authored-By: CyrusNajmabadi <cyrus.najmabadi@gmail.com>

…ocument.GetLanguageService<ISyntaxFactsService>().

… the identifier escaping for keywords.

Change Roslyn to target netcoreapp3.1 when building .NET Core assets.

Previously the code targetted a mix of netcoreapp2.1 and netcoreapp3.0.
The mix is due to default interfaces only being supported on
netcoreapp3.0 and hence our testing needed to use that. Yet at the same
time we were required to ship the compiler in SDKS that targetted
netcoreapp2.1. Now we can universally target netcoreapp3.1.

dotnet/msbuild#4806

Decided to remove the property based approach to specifying a target
framework to just specifying `netcoreapp3.1` directly. The reason for
this is the following:

The advantage of the property is it makes it "easy" to change to a new
target framework in the future. That benefit is actually pretty minimal.
A simple find and replace operation is **extremely** effective in our
code base (it's less key strokes than this message). Hence the benefit
is minimal.

The downside of the property is that our code doesn't look like customer
code. Or rather it diverges from the practices that we publish. In
general I prefer to keep our code as standard as possible unless there
is a good reason to deviate. There just doesn't seem to be one here.

The TPA now considers the output directory as a trusted place for
loading assemblies. To the point it will prefer certain DLLs in the
output directory over equal ones that ship with the runtime.

This broke a number of VB tests here because we unconditionally
referenced the desktop version of Microsoft.VisualBasic. This got copied
to the output directory, included in the TPA and hence loaded during
test execution. This breaks tests because they require the .NET Core
version of Microsoft.VisualBasic.

Conditioned the reference to be desktop only so it's not present on our
.NET Core builds

Had to clean up a few nullable annotations now that we are compiling
agaist `netcoreapp3.1` and hence get the full value of the framework
annotations.

This is also problematic though because there are now two places where
the compiler can see nullable attributes that are directly used by the
developer. For example `NotNullWhenAttribute`. This is both defined in
our assemblies for non-netcoreapp target frameworks and provided by the
SDK when targeting `netcoreapp3.1`.

This causes a problem for assemblies which have the following
characteristics:

1. Target `netcoreapp3.1`
1. Reference an assembly targeting `netstandard2.0` which uses our
nullable attributes definition
1. Has IVT into (2) above

These properties essentially define all of our unit test assemblies. In
that environment it's not possible to use nullable attributes in code
because the compiler can't disambiguate which definition of
`NotNullWhenAttribute` to use. This meant I had to temporarily remove a
few attributes until we can complete dotnet#40766.

Closes dotnet#41304

* Update dependencies from https://github.com/dotnet/arcade build 20200129.8

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.20079.8

* Update dependencies from https://github.com/dotnet/arcade build 20200130.4

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.20080.4

Name suggestions don't contain suggestions starting with a digit.

Target netcoreapp3.1

Make ValueText return empty instead of null

Fix issues in MetadataAsSource XML documentation comment conversion

* Fix Pythia pooled objects wrappers

* Fix RPC

Fix for Visual Studio crashes when adding a parameter to a function

…mplification-arglist

Stop Simplifier.ReduceAsync removing empty arg lists from delegates