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

Clarify use of assert! and debug_assert! in the documentation #34455

Closed
snowe2010 opened this issue Jun 24, 2016 · 7 comments
Closed

Clarify use of assert! and debug_assert! in the documentation #34455

snowe2010 opened this issue Jun 24, 2016 · 7 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@snowe2010
Copy link
Contributor

A discussion with @gnzlbg lead us to determine that the proper way to use assert! and debug_assert! is confusing. It could be clarified in the documentation as to how they should be used, e.g. proper use in production, proper use for debugging.

@steveklabnik steveklabnik added A-docs E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Jun 24, 2016
@steveklabnik
Copy link
Member

I would be happy to work with anyone who wants to tackle this issue

@gnzlbg
Copy link
Contributor

gnzlbg commented Jun 27, 2016

I don't know how easy this is. assert! is used in unsafe code to maintain run-time invariants, that if violated, could lead to unsafety (this use case is a bit advanced).

At the same time, both assert! and debug_assert! are used in both safe and unsafe code to maintain invariants that should be checked (at least in debug builds), but that do not lead to memory unsafety (only e.g. logic errors).

Finally, assert! is also used for unit-testing (with assert_eq!). These are three distinct use cases.

From other programming languages that I know, these second use-case is what I typically relate with assertions. Those programming languages, however, don't have the safe/unsafe code distinction.

I guess I would write something like:

assert! is a macro that ensures the termination of a program if a condition is not satisfied by means of an unrecoverable error (not necessarily a panic!, can also be an abort). Assertions are always checked in both debug and release builds, and cannot be disabled. Unsafe code relies on assert! to enforce run-time invariants that, if violated, could lead to unsafety.

Other use-cases of assert! include testing (with a link to testing) and enforcing run-time invariants in safe code (whose violation cannot result in unsafety). The debug_assert! macro allows disabling checking for the assertions at build time (debug_test = false). An unchecked assertion allows a program in an inconsistent state to keep running, which might have unexpected consequences but does not introduce unsafety as long as this only happens in safe code. The performance cost of assertions is, however, not measurable in general. Replacing assert! with debug_assert! is thus only encouraged after throughrough profiling, and more importantly, only in safe code!

@steveklabnik
Copy link
Member

I guess my thinking is that this is technically easy: you just have to know where to add the text. Part of what I imagine working with someone on here is exactly how it's presented.

On Jun 27, 2016, 19:40 -0400, gnzlbgnotifications@github.com, wrote:

I don't know how easy this is.assert!is used in unsafe code to maintain run-time invariants, that if violated, could lead to unsafety (this use case is a bit advanced).

At the same time, bothassert!anddebug_assert!are used in both safe and unsafe code to maintain invariants that should be checked (at least in debug builds), but that do not lead to memory unsafety (only e.g. logic errors).

Finally,assert!is also used for unit-testing (withassert_eq!). These are three distinct use cases.

From other programming languages that I know, these second use-case is what I typically relate with assertions. Those programming languages, however, don't have the safe/unsafe code distinction.

I guess I would write something like:

assert!is a macro that ensures the termination of a program if a condition is not satisfied by means of an unrecoverable error (not necessarily apanic!, can also be anabort). Assertions are always checked in both debug and release builds, and cannot be disabled. Unsafe code relies onassert!to enforce run-time invariants that, if violated, could lead to unsafety.

Other use-cases ofassert!include testing (with a link to testing) and enforcing run-time invariants in safe code (whose violation cannot result in unsafety). Thedebug_assert!macro allows disabling checking for the assertions at build time (debug_test = false). An unchecked assertion allows a program in an inconsistent state to keep running, which might have unexpected consequences but does not introduce unsafety as long as this only happens in safe code. The performance cost of assertions is, however, not measurable in general. Replacingassert!withdebug_assert!is thus only encouraged after throughrough profiling, and more importantly, only in safe code!


You are receiving this because you commented.
Reply to this email directly,view it on GitHub(#34455 (comment)), ormute the thread(https://github.com/notifications/unsubscribe/AABsiqa3I1j4AWbZYSHudcR5UbdsHOrWks5qQF-GgaJpZM4I991n).

@munyari
Copy link
Contributor

munyari commented Jul 26, 2016

@steveklabnik I'd like to work on this with you. Where should one begin?

@steveklabnik
Copy link
Member

@munyari great! So, https://github.com/rust-lang/rust/blob/master/src/libcore/macros.rs#L33-L60 and https://github.com/rust-lang/rust/blob/master/src/libcore/macros.rs#L111-L145 are where the text goes.

What do you think about @gnzlbg 's draft of the comments? Feel free to open a PR (I can help walk you through that too if you need) with it, or some variant of it, in your own words, and we can go from there 😄

@munyari
Copy link
Contributor

munyari commented Jul 27, 2016

Just opened a PR @steveklabnik 😄

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jul 29, 2016
@brson
Copy link
Contributor

brson commented Jul 30, 2016

Thanks @munyari !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Development

No branches or pull requests

5 participants