This is what is forcing all the ImmutableArray<Location?> annotation changes. #ByDesign

elementLocations [](start = 34, length = 16)

elementLocations [](start = 34, length = 16)

Should the type of elementLocations be adjusted in public API then, so we avoid the suppression? #Closed

I don't think so. If you're creating this from a public context, you should pass real locations as more of a matter of principle.

In reply to: 367179639 [](ancestors = 367179639)

Just to clarify: When do we need to pass null locations internal?
Maybe we can mark as non-nullable across the board...

In reply to: 370338279 [](ancestors = 370338279,367179639)

ImmutableArray<Location?> elementLocations [](start = 12, length = 42)

what prompted that change?
Do we need a test for Compilation.CreateTupleTypeSymbol passing null locations? (I couldn't find one) #Closed

#40946 (comment) #Closed

boundNamedArgumentsBuilder == null [](start = 28, length = 34)

consider changing this test to check boundNamedArgumentsSet instead, since the two locals are always initialized together (or not), then the suppression can be removed. #WontFix

Our approach for nullable has been to not change any semantic behavior, just to annotate what we are currently doing. I'm going to keep this going forward.

In reply to: 367181664 [](ancestors = 367181664)

namedArgument.NameEquals [](start = 46, length = 24)

consider using an assertion instead #Closed

NameEquals [](start = 47, length = 10)

consider using an assertion here too (and at least one more place below) #Closed

name [](start = 38, length = 4)

consider asserting instead #Closed

results [](start = 53, length = 7)

why this suppression? #Closed

RemoveInvalidConstraints takes a non-null arraybuilder. We started with some nulls in the array, but just went through the whole thing to remove it.

In reply to: 367182789 [](ancestors = 367182789)

Type [](start = 38, length = 4)

how do we know source.Type isn't null from surrounding code?
If we know because of some remote code, then assertion seems preferable.

Note: a few lines below we do a null-test on source.Type #Closed

Note: a few lines below we do a null-test on source.Type

BindToNaturalType should take care of that, but I'll add an assert.

In reply to: 367183378 [](ancestors = 367183378)

ContainingType [](start = 43, length = 14)

Is the suppression okay because InFieldInitializer is true at this point? #Closed

Correct.

In reply to: 367183871 [](ancestors = 367183871)

destination [](start = 24, length = 11)

Should destination be declared as nullable? #Closed

The only callers pass non-null.

In reply to: 367184280 [](ancestors = 367184280)

destination [](start = 103, length = 11)

Can't destination be null here? Seems dangerous #WontFix

The null check above is actually superfluous.

In reply to: 367184489 [](ancestors = 367184489)

Sorry, I'd missed your reply. Consider removing the superfluous null check so that we don't need those suppressions.
Suppressions are typically for when the compiler is not able to analyze properly, but here it's rather that the code is inconsistent (checks for null in one place, but would blow up with null in another).

In reply to: 370290111 [](ancestors = 370290111,367184489)

I'm not going to change the semantics of the code in this PR.

In reply to: 375590101 [](ancestors = 375590101,370290111,367184489)