Latest lint writes formatDiagnosticLog.binlong next to the solution file when running with --verbosity diagnostic. There's no way to redirect or disable this - dotnet/format#1041.

So this change disables --verbosity diagnostic for local runs of lint and adds it only to the CI (where the machine will clean the enlistment anyway).

…y and MakeGenericMethod (#1880)

Adds the ability to track some basic patterns around `MethodBase`/`MethodInfo`. Linker now recognizes `ldtoken` for a method as well as tracks return value of `Type.GetMethod`.

With this, the change implements two improvements:

#1814 - Mark property as accessed via reflection when using Expression.Property(Expression,MethodInfo)

Added a new warning to report cases where the intrinsic handling of the Property call doesn't work.

#1727 - Ability to handle simple MakeGenericMethod calls without generating a warning

If the generic method has no annotations on the generic arguments, linker will no longer warn.

Added tests for all the new behaviors.
Improved tests for MakeGenericMethod and MakeGenericType.
Implement checking for new constraint in MakeGenericType - it now behaves the same as if the generic argument is annotated.

If the type has a custom attribute which will cause MarkEntireType on the type itself (for example through data flow annotation), we will end up recursively calling MarkEntireType with the same input - leading to stack overflow.

The existing protection against SO in MarkEntireType is not enough since it only works on immediate recursion, not through custom attribute marking.

So moved the hashset of entire types marked as global on MarkStep, which prevents the recursion no matter the codepath.

…1888)

`struct` and `unmanaged` constraint also imply `new()` constraint, but any type allowable for `struct` or `unmanaged` constraints always has public parameterless constructor. Or rather the type can be constructed without parameters (the .ctor itself is actually not accessible through reflection).

Since MakeGenericType and MakeGenericMethod both enforce that only types compatible with `struct` or `unmanaged` constraints can be passed as type arguments to such generic parameters, there's no need for linker to validate this as well. At runtime it will always work - and on top of that, there's nothing for linker to mark - struct and unmanaged don't have a parameterless .ctor in IL - it's just that at runtime they behave as if they do.

So enforcing the `new()` constraint in `MakeGenericMethod` or `MakeGenericType` makes sense only when it's just `new()` constraint, not if it's implied from `struct` or `unmanaged` constraints.

* Change the behavior to not relax but instead single out Nullable<> as a special case.

Nullable<> doesn't make use of the implied new() constraint, so there's no reason for linker to enforce it. It's by far the most common case where this is problematic - that's why the special handling.

…1870)

…310.7 (#1893)

[main] Update dependencies from dotnet/arcade

…0314.8 (#1894)

[main] Update dependencies from dotnet/runtime

)

* Cctor marked because of accessed field should trigger warning

* Ignore testcase in analyzer

* Add tests
Move field initialization to cctor

* Add beforefieldinit test to list of tests ignored by the analyzer

* Fix testname

Fixes #1717