ILVerify check improvements

[Martin521]

The new ILVerify check in CI certainly makes sense.

Here are just some inconveniences I met.

• In most cases, there are just changes in line numbers.
• In this case, there was probably some whitespace change at the end of the line, caused by a merge editor.

Can we assume "success" in these cases?

Or, more specific, implement this logic:

if baseline does not exist then
  run ilverify
  if TEST_UPDATE_BSL=1 then
    save output as .bsl
  else
    save output as .actual
  success
else
  run ilverify
  if output = baseline then
    success
  else
    show differences
    if TEST_UPDATE_BSL=1 then
      save output as .bsl
    else
      save output as .actual
    if output differs from baseline only in line numbers or line-end whitespace then
      success
    else
      failure

If that makes sense, I can support implementing it.

[vzarytovskii]

I think it instead should be fixed. This particular issue, which is causing all those unexpected stack errors is fixable in one place in the compiler.

I considered ignoring line numbers, but decided not to. I'll leave it to the team to decide what to do.

[T-Gro]

@Martin521:

It would be definitely better to address the warnings it produces.

The line numbers are coming from compiler generated code , which includes the LOC number in the name. If anything code is added above, the name also changes.
If baseline differs only in a single number, but all other parts of the generated closure will be the same and also the amount of same named generated members will be the same (the numbers are also there to prevent duplicates) => this could work.

i.e. this part would be a good improvement if output differs from baseline only in line numbers or line-end whitespace then, at least until the underlying reason for ilverification failure is fixed.