Skip to content
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

Make debugging in release build a compiler error #43

Closed
wants to merge 2 commits into from

Conversation

jlapeyre
Copy link
Collaborator

This commit adds macros ddbg and dprintln, which are defined in debug builds, but not in release builds. So, if they appear in code they will result in a compile time error when doing a release build. These are only added to the oq3_semantics crate. They would have to be duplicated to use them in other crates. Or perhaps moved to the lexer crate, which all others depend on, directly or indirectly.

Using these requires also #[cfg(debug_assertions)] when importing them.

I have seen an implementation of something similar that includes a definition of the macros for release builds. This does not then require #[cfg(debug_assertions)] on import. We could do something similar, by making ddbg expand to something that fails to compile, say references an undefined variable. But that would not be very robust.

There is a probably a standalone, registered, crate to do things like this. But I was unable to find such a crate. Nor did I find online any reference to the basic problem this is meant to solve.

This commit adds macros ddbg and dprintln, which are defined in debug builds, but not
in release builds. So, if they appear in code they will result in a compile time
error when doing a release build. These are only added to the oq3_semantics crate.
They would have to be duplicated to use them in other crates. Or perhaps moved to the
lexer crate, which all others depend on, directly or indirectly.

Using these requires also #[cfg(debug_assertions)] when importing them.

I have seen an implementation of something similar that includes a definition of the
macros for release builds. This does not then require #[cfg(debug_assertions)] on
import. We could do somehting similar, by making ddbg expand to something that fails
to compile, say references an undefined variable.  But that would not be very robust.

There is a probably a standalone, registered, crate to do things like this. But I was unable to
find such a crate. Nor did I find online any reference to the basic problem this is meant to solve.
@jlapeyre jlapeyre marked this pull request as draft January 18, 2024 00:57
@jlapeyre
Copy link
Collaborator Author

Converted to draft mode. Half of what this PR (#43) does is done much better in

But #47 does nothing to replace other half of #43 , that is dprintln! .

@jlapeyre
Copy link
Collaborator Author

I'll close this. It could be re-opened later, if println! for debugging creeps into the main branch.

@jlapeyre jlapeyre closed this Jan 21, 2024
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.

1 participant