fixes #17437 - crash where error reporting > 1

[saem]

Crash occurs in cases where max error reporting is greater than 1 and an object
constructor error exists in a proc body.

Without this the tracking done in semProcAux will assume construction was
successful and not be able to handled the non-semmed nodes.

Scenarios where this occurs:

• nimsuggest
• nim check
• nim with errorMax > 1

This is also generally the correct direction nudging us towards proper nkError.

fixes #17437

[dom96]

Suggestion: to make it easier to go through notifications, include more detail about the issue in the PR title.

[saem]

Huh, why didn't [skip ci] work?

[timotheecour]

Huh, why didn't [skip ci] work?

• why CI pipelines did it not skip?
  we have:;

.github/workflows/ci_docs.yml:34:105:      !contains(format('{0} {1}', github.event.head_commit.message, github.event.pull_request.title), '[skip ci]')
.github/workflows/ci_packages.yml:7:105:      !contains(format('{0} {1}', github.event.head_commit.message, github.event.pull_request.title), '[skip ci]')

• i think we need to add similar logic to azure-pipelines.yml, because of [skip ci] semantics is badly broken microsoft/azure-pipelines-agent#2944
• we need to update contributing.rst docs, which currently say:

doc/contributing.rst:464:39:   documentation only changes), add `[ci skip]` to your commit message title.

(ci skip vs skip ci)

[saem]

Thanks, @timotheecour.

Hmm, I wonder if we could do something like have one pipeline stage before everything, which can detect if the change is meaningful and conservatively do a skip? (just seeding a thought to think about in the background, no action needed)

[timotheecour]

Hmm, I wonder if we could

@saem in the spirit of "1 topic, 1 issue", let's move this discussion to timotheecour#675