Skip to content

Demangling: always build with NDEBUG #19258

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 12, 2018

Conversation

compnerd
Copy link
Member

Avoid a dependency on LLVMSupport at runtime through the llvm_unreachable.
This would pull in llvm_unreachable_internal in debug builds, which requires a
runtime dependency on LLVMSupport which increases the size of the binary
considerably. Always build with NDEBUG. Note that this effectively always
builds the Demangling library WITHOUT asserts :-(.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@compnerd
Copy link
Member Author

CC: @jrose-apple @eeckstein

@compnerd
Copy link
Member Author

@swift-ci please test

@jrose-apple
Copy link
Contributor

I don't like this. Can we use something other than llvm_unreachable instead?

@compnerd
Copy link
Member Author

@jrose-apple - we could use LLVM_BUILTIN_UNREACHABLE to indicate to the compiler that the switch is exhaustive, but we would lose the message (which we do anyways with this, so its not so terrible).

@slavapestov
Copy link
Contributor

I would much rather keep the asserts and fix this problem some other way.

@compnerd
Copy link
Member Author

@slavapestov - I really don't like the idea of providing an alternative implementation of llvm_unreachable_internal.

@compnerd compnerd force-pushed the demangling-reachability branch from f133a01 to 58f8f68 Compare September 11, 2018 23:26
@compnerd
Copy link
Member Author

At least the build will be aborted with this version. @slavapestov - suggestions welcome :-)

@jrose-apple
Copy link
Contributor

Okay, actually all of these unreachables come after default: return false, so it shouldn't matter. We wouldn't even need them if we always compiled with Clang. This seems fine to me (but Erik should still take a look).

@slavapestov
Copy link
Contributor

We could use assert(false && ...) instead of llvm_unreachable in the demangler.

@compnerd
Copy link
Member Author

@slavapestov - yeah, I suppose assert should be a strong enough hint. I'm gonna let @eeckstein make the call between leaving the LLVM_BUILTIN_UNREACHABLE and assert(0 && "...");.

@eeckstein
Copy link
Contributor

Using assert sounds good to me

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - f133a0120f489425d3e92921afb34cdfda4df6aa

Avoid a dependency on LLVMSupport at runtime through the `llvm_unreachable`.
This would pull in `llvm_unreachable_internal` in debug builds, which requires a
runtime dependency on LLVMSupport which increases the size of the binary
considerably.
@compnerd compnerd force-pushed the demangling-reachability branch from 58f8f68 to 9105eb3 Compare September 12, 2018 05:10
@compnerd
Copy link
Member Author

@swift-ci please test and merge

1 similar comment
@compnerd
Copy link
Member Author

@swift-ci please test and merge

@compnerd
Copy link
Member Author

@swift-ci please test macOS platform

@compnerd compnerd merged commit d15d752 into swiftlang:master Sep 12, 2018
@compnerd compnerd deleted the demangling-reachability branch September 12, 2018 22:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants