Re-enable debug and LLVM assertions

[Mark-Simulacrum]

Historically we've disabled these assertions on a number of platforms with the
goal of speeding up CI. Now, though, having migrated to GitHub actions, CI is
already pretty fast, and these debug assertions do bring us some value.

This does leave in some debug assertions that are performance-related: macOS
currently hovers at just under 2 hours.

There are also some other builders which have debug and LLVM assertions
disabled:

llvm-8, PR builder:

In one view, this builder tests our support for older LLVMs. But in reality, a
lot of our tests already disable themselves on older LLVMs, and I think our
general stance is that we really only support the in-tree LLVM. Plus, we really
want CI times on this builder to be really low, as it's run on every PR --
that's a lot of CI time.

test-various:

This disables debug asserts still -- as noted in the Dockerfile, we test code
size, and we need debug asserts off for that to work well.

Helps with #59637 -- but doesn't close it, macOS still has asserts off.

r? @pietroalbini

[Mark-Simulacrum]

@nikic @cuviper (I guess we need an LLVM alias that's more "team" oriented rather than the ping group):

Do you agree that my interpretation of the llvm-8 builder is accurate? Should we be running debug asserts on it on the auto branch perhaps?

[cuviper]

llvm-8, PR builder:

In one view, this builder tests our support for older LLVMs. But in reality, a
lot of our tests already disable themselves on older LLVMs, and I think our
general stance is that we really only support the in-tree LLVM.

Well, you already know that external LLVM support is important to me for distro needs. I think this builder is useful as a sanity check, both that external LLVM works and that the stated minimum is explicitly maintained. That's true even without full testing -- just the fact that it bootstraps successfully will catch a lot.

The setting for LLVM assertions is irrelevant there, since it's not building LLVM. Rust debug assertions are debatable, but I agree it's nice to keep this fast for first-line pull request CI. Do you know how much that would slow it down?

[Mark-Simulacrum]

That's certainly true. I didn't intend to imply that external LLVM support isn't needed, more so that super recent LLVM is what is guaranteed to work -- we've had soundness fixes and such I think by way of LLVM patches, upstreamed. Maybe I'm misremembering that though.

It's a good point though that since we're not building LLVM the assertions setting doesn't matter.

I don't know how much of a slow down debug assertions would be on the PR builder -- I can try and test that a bit, I guess, just rerunning the builder on this PR a few times after pushing up an amendment. I'll do that soon.

---

Using as a record of timings so far:

• Without asserts: 33m, 33m
• With asserts: 42m, 43m, 44m, 37m, 41m, 42m, 37m

[pietroalbini]

@Mark-Simulacrum what about disabling assertions in PR llvm-8, and enabling them in auto llvm-8?

[Mark-Simulacrum]

Yeah I'd rather not diverge the builders like that -- makes it even more annoying to debug auto builder failures if we have differing behaviors between PR and not PR.

[nikic]

FWIW I don't think debug assertions are particularly useful for the LLVM 8 builder -- having LLVM assertions there would be useful, but not really possible with distro packages. Having debug assertions there would only catch the pretty narrow case of an older LLVM version miscompiling code inside a debug assertion specifically...

[cuviper]

It's not useful for LLVM's sake, but debug assertions may still catch if a pull request introduces a bug in general, and it's nice if we can do that before the review and full CI.

The LLVM 8 builder is chosen for this just because it runs automatically, since it's faster without building LLVM itself.

[Mark-Simulacrum]

So adding debug assertions to the PR builder seems like a 6-8 minute hit (roughly 33 to 40m). I don't really care much either way.

[bors]

☔ The latest upstream changes (presumably #73383) made this pull request unmergeable. Please resolve the merge conflicts.

[pietroalbini]

I'm ok with the current changes, I agree that testing assertions on llvm-8 is not crucial. r=me once the merge conflict is fixed.

[Mark-Simulacrum]

@bors r=pietroalbini

[bors]

📌 Commit 2ca5d0d150d9da70b57c279a72255812d3ef6d2b has been approved by pietroalbini

[bors]

⌛ Testing commit 2ca5d0d150d9da70b57c279a72255812d3ef6d2b with merge eaccf682adaf879b494c8bee7363b5b83fcb1ffb...

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

My hope is that this will now just pass (with #76859 merged).

@bors r=pietroalbini rollup=never

[bors]

📌 Commit 3ca8829 has been approved by pietroalbini

[bors]

⌛ Testing commit 3ca8829 with merge 8e20c1e26dd4438a133e5a99acc7b4ef0c5cb958...

[bors]

💥 Test timed out

[Mark-Simulacrum]

@bors retry

AFAICT, the powerpc dist builder is still running, but this PR doesn't touch it to my knowledge.

[bors]

⌛ Testing commit 3ca8829 with merge d6f4abe8ca3ed385639ed9bbe6c10e56b688f0d9...

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

2020-11-07T05:28:32.4615266Z FAILED: sccache /usr/bin/c++   -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/ProfileData -I/checkout/src/llvm-project/llvm/lib/ProfileData -Iinclude -I/checkout/src/llvm-project/llvm/include -ffunction-sections -fdata-sections -fPIC -m64 -static-libstdc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MMD -MT lib/ProfileData/CMakeFiles/LLVMProfileData.dir/GCOV.cpp.o -MF lib/ProfileData/CMakeFiles/LLVMProfileData.dir/GCOV.cpp.o.d -o lib/ProfileData/CMakeFiles/LLVMProfileData.dir/GCOV.cpp.o -c /checkout/src/llvm-project/llvm/lib/ProfileData/GCOV.cpp
2020-11-07T05:28:32.4624500Z <built-in>: internal compiler error: Segmentation fault
2020-11-07T05:28:32.4625139Z Please submit a full bug report,
2020-11-07T05:28:32.4625673Z with preprocessed source if appropriate.
2020-11-07T05:28:32.4627542Z See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
2020-11-07T05:28:37.8020856Z ninja: build stopped: subcommand failed.

Seems spurious, @bors retry

[bors]

⌛ Testing commit 3ca8829 with merge b2d115f...

[bors]

☀️ Test successful - checks-actions
Approved by: pietroalbini
Pushing b2d115f to master...