Open sbomer opened 2 years ago
I found another example:
MethodInfo noValue = typeof (MakeGenericMethod).GetMethod (null);
// Warns even though GetMethod throws at runtime.
noValue.MakeGenericMethod (typeof (TestType));
https://github.com/dotnet/linker/pull/2694 fixed this for Type.BaseType
.
BTW @vitek-karas I realized that another way to think about this is that the BaseType
behavior violated monotonicity of the transfer functions (which in general is required for the dataflow analysis to converge). So if x <= y
in the lattice, then we should have Intrinsic(x) <= Intrinsic(y)
. But for BaseType
, we had BaseType({All}) = {All}
and BaseType({}) = {None}
- where {All} <= {}
, but it's not true that {All} <= {None}
.
That's a good point!
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas See info in area-owners.md if you want to be subscribed.
https://github.com/dotnet/linker/pull/2652 added tests that showed a few cases where intrinsics produce warnings for
null
inputs even when they throw at runtime. The intrinsic handling falls back on the annotated return values, which warn if they flow into methods with requirements that aren't satisfied by the return annotation.A similar issue exists for "empty" inputs flowing to intrinsics (the empty inputs represent unimplemented intrinsics in the analyzer, which should not warn, or values produced from intrinsics that are known to throw at runtime). In a few intrinsics, we propagate the "empty" input, while in others, we fall back on annotations.
My suggestion would be to consistently avoid producing warnings for these cases, and return "empty" from intrinsics that we know would throw, or which receive an "empty" value.