-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
bazel,dev: in dev
, handle different --compilation_mode
s correctly...
#106944
Conversation
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
} | ||
if arg == "--config" || arg == "--compilation_mode" || arg == "-c" { | ||
ret = append(ret, arg) | ||
addNext = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nit. You can add continue
here, so you don't even try to evaluate the next if
(and potential future ifs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used if .. else if
for this to accomplish the same thing without using continue
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right. nm then!
... and switch our default compilation mode to `dbg`. Under `fastbuild`, built binaries are stripped. This is not the case with `dbg`. Have `dev doctor` recommend using `dbg`, and either way make `dev` resilient to whatever kind of `--compilation_mode` you're using. In principle or theory `dbg` is slower than `fastbuild`, but for the Go compiler it generates debuggable binaries by default and you have to opt-in to stripping, so it shoould make no real difference. Now, we think of the `--compilation_mode` simply as follows: `dbg` is the default that everyone is opted into by default unless they explicitly set `-c opt` (we use this for release). For now I don't see a reason anyone would need `fastbuild`. Epic: CRDB-17171 Release note: None Closes: cockroachdb#106820
bors r=rail |
Build failed (retrying...): |
Build succeeded: |
In cockroachdb#106944 the `dbg` compilation mode became the default for all non-release builds. This caused stack overflows in the memo cycle detection tests, which excessive invoke recursive functions, likely because stack frames are larger in `dbg` mode than in `opt` mode or because certain optimizations aren't performed in `dbg` mode that reduce stack depth due to recursion, like inlining. This commit fixes the test by lowering the cycle detection limit, making it so that a cycle is detected before a stack overflow occurs. Epic: None Release note: None
Follow-up: #107207 |
... and switch our default compilation mode to
dbg
.Under
fastbuild
, built binaries are stripped. This is not the case withdbg
. Havedev doctor
recommend usingdbg
, and either way makedev
resilient to whatever kind of--compilation_mode
you're using.In principle or theory
dbg
is slower thanfastbuild
, but for the Go compiler it generates debuggable binaries by default and you have to opt-in to stripping, so it shoould make no real difference.Now, we think of the
--compilation_mode
simply as follows:dbg
is the default that everyone is opted into by default unless they explicitly set-c opt
(we use this for release). For now I don't see a reason anyone would needfastbuild
.Epic: CRDB-17171
Release note: None
Closes: #106820