[BUG]: "Execution compiler" warning output seems to be cached and un-clearable-from-cache

[Quuxplusone]

Describe the bug

As reported on the cpplang Slack a few days ago. Unfortunately, it looks like the cache has expired now, so the first URL below no longer reproduces the weird result. Sorry!

I've got a weird bug (perhaps) in my recently-repushed/built p1144 branch on godbolt.org.
https://p1144.godbolt.org/z/eo46jqPPf
I built this source a few days ago before p1144 supported -Wctad, and, as expected, got warning: unknown warning option '-Wctad'; did you mean '-Wctu'? [-Wunknown-warning-option] from both the "ASM generation" and "Execution build" compiler steps.
Then I pushed my p1144 branch and waited 24 hours. So now I expect different behavior from the p1144 compiler.
Then I clicked the "swirly arrow" button to rebuild this source code. (Reloaded the page and so on, too.)
What I see now is that the "ASM generation compiler" understands -Wctad, but the "Execution build compiler" step is still giving warning: unknown warning option '-Wctad'; did you mean '-Wctu'? [-Wunknown-warning-option].

I wonder if both the "Execution build compiler" and "ASM generation compiler" outputs are cached, but the swirly-arrow button recomputes only the "ASM generation compiler" output. Or perhaps it recomputes "Execution build" if and only if the actual assembly output has changed, but otherwise assumes that same assembly means same executable. That, also, is a bad assumption, if there have been changes to the assembler/linker toolchain in the meantime.

Add a space to the input, so it's a novel input, and the "Execution build compiler" behaves as expected: https://p1144.godbolt.org/z/P5s5dEcbj

Steps to reproduce

As described above. You can probably reproduce this yourself if you control a compiler and can make it do something detectable in the warning output. Even #warning __CLANG_VERSION__ (or whatever is the minor version number macro that increments on every build) ought to do the trick.

Expected behavior

As described above. Clicking the swirly arrow to clear the cached results and rebuild should also clear the cached results of the "Execution build compiler."

Reproduction link

Not applicable

Screenshots

Not applicable

Operating System

No response

Browser version

No response

[AbrilRBS]

Hi! Thanks for the detailed report, we really appreciate it. You seem to be onto something, we'll try to find the faulty logic, but cache invalidation is always tricky.

[jeremy-rifkin]

I think this should be fixed by #5111, which reworked quite a lot about how caching is done, if I'm understanding correctly.

Prior to that PR handleExecution was called with the cache key but nothing to indicate that the cache should be bypassed

compiler-explorer/lib/base-compiler.ts

Lines 2592 to 2593 in 910d69f

	// Start the execution as soon as we can, but only await it at the end.
	const execPromise = doExecute ? this.handleExecution(key, executeParameters) : null;

Now there is a flag to indicate that the cache check in handleExecution should be bypassed.

compiler-explorer/lib/base-compiler.ts

Lines 2631 to 2632 in 07b0df5

	// Start the execution as soon as we can, but only await it at the end.
	const execPromise = doExecute ? this.handleExecution(key, executeParameters, bypassCache) : null;