[CSSimplify] Add a null check to guard against broken/missing `Expres…

[xedin]

…sibleByNilLiteral`

I couldn't come up with an isolated test-case to add to the suite,
but it's possible that getProtocol returns nullptr for invalid
or missing protocol so there has to be a check for that otherwise
compiler is going to crash trying to access getDeclaredType().

Resolves: rdar://76187450

[xedin]

@swift-ci please smoke test macOS platform

[xedin]

@swift-ci please smoke test Linux platform

[slavapestov]

Is this the same bug as where the stdlib fails to load but we keep compiling? There are too many places in the compiler that rely on stdlib declarations being present, and we can't fix all of them. The right solution is to stop the build if the stdlib doesn't load. I believe @beccadax was working on this.

[xedin]

@slavapestov I'm not sure if it is or not since I don't have access to log just the stacktrace of the crashed thread.

[hamishknight]

Since #32091, we should bail early if the stdlib fails to load.

[xedin]

So it's either something else or that code doesn't cover all the cases...

[hamishknight]

Does the crash happen through the FrontendTool's performCompile, or is it through another bit of tooling that sets up its own CompilerInstance? I see #36797 recently added a stdlib check for SourceKit, could that be related?

[xedin]

@hamishknight swift::CompilerInstance::performSema(). It's possible that SourceKit does something special which then works around changes you mentioned

[xedin]

@swift-ci please smoke test macOS platform

[ahoppen]

It's possible that SourceKit does something special which then works around changes you mentioned.

We shouldn’t be doing anything special regarding stdlib loading. If your crash is related to the stdlib not being loaded (which I suspect), this should be caught by the check added in #36797.

[xedin]

Good to know, @ahoppen! I still going to merge this null check just to feel better, I think other places in the solver should handle situations like that gracefully as well, in case there is some other edge case, crashing at random points isn’t great...

[hamishknight]

It's possible that SourceKit does something special which then works around changes you mentioned.

Right, yeah SourceKit sets up its own CompilerInstance rather than going through FrontendTool's performCompile, so it wouldn't have been caught by the check added in #32091, but should be caught by the check added in #36797. I'm more than happy for us to add this null check though.