Uh oh!
There was an error while loading. Please reload this page.
Fix null check in S.Diagnostics.Contract regressed by nullability annotations - #41382
Conversation
krwq
commented
Aug 26, 2020
@danmosemsft this one has a bit smaller scope I think but it does affect Code Contracts (is anyone even using it still?) |
5fa6bde to
2482f61Compare| { | ||
| Assembly? caller = stack.GetFrame(i)!.GetMethod()?.DeclaringType!.Assembly; | ||
| MethodBase stackMethod = stack.GetFrame(i)!.GetMethod(); | ||
| Assembly? caller = (stackMethod != null) ? stackMethod.DeclaringType!.Assembly : null; |
There was a problem hiding this comment.
DeclaringType can be null. I do not think there is anything guaranteeing that it will be non-null here. This is one of those cases nullable annotations caught a real bug.
Should the fix be to just change ! after DeclaringType to ?? No need to split it into multiple lines.
There was a problem hiding this comment.
We try to avoid any product changes during nullability annotations as those are always risky and can get lost in a large PR. In this case since PR is only affecting this specific change so I think we should fix it.
jkotas
commented
Aug 27, 2020
What are the tests that caught this? |
krwq
commented
Aug 27, 2020
carlossanlop
commented
Aug 27, 2020
/backport to release/5.0 |
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/227480299 |
While annotating #41261 I've introduced a product bug which luckily got caught by tests. It is weird compiler behavior (dotnet/csharplang#3393) which changes
?.precedence when adding!, see i.e.:https://sharplab.io/#v2:EYLgtghgzgLgpgJwDQBMQGoA+ABATARgFgAoEvAZgAIBvEy+y7fANkYBZKAFCGAC3wAUAYXyUADgEoadBrIBuEBJQB2EMHEoBecQH4AdENx6AcmrgBuGbPpMAnANXqJl4rIC+Vyp6atsHbny4wqKS0q7W9ApKjhraYvqGAIQmZi4RNvj2Mc6eHsR5ZLiUIiS04TZUhsVF1JQA5nAw5pRQjc15BcR41aXeVEwADJSm6jT1bS1tHUA
Note: this is fixing a regression introduced by a8b7c22#diff-918e20adb7bd65c2e6e73caa106465d6R658