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

Convert assert to a macro/library function #2228

Closed
brson opened this issue Apr 17, 2012 · 8 comments
Closed

Convert assert to a macro/library function #2228

brson opened this issue Apr 17, 2012 · 8 comments
Labels
A-codegen Area: Code generation A-frontend Area: Compiler frontend (errors, parsing and HIR) A-grammar Area: The grammar of Rust E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Apr 17, 2012

I don't think there are any obstacles to making this a function. The only difference is that it will require parens.

Remember to change the docs.

@nikomatsakis
Copy link
Contributor

I would rather see a macro so that (1) we can still see the text of the expression which failed and (2) the line number is the line number that made the assertion, not some piece of code in core::util::assert.

@brson
Copy link
Contributor Author

brson commented Apr 17, 2012

Yep, you're right.

@graydon
Copy link
Contributor

graydon commented Apr 17, 2012

Yeah, we'll need syntax extensions for #file and #line first, as well as #stringify or something. But we should have those anyways.

@catamorphism
Copy link
Contributor

I opened an issue - #2245 - for the #file and #line macros that we need for this.

@Dretch
Copy link
Contributor

Dretch commented May 24, 2012

If rust backtraces included line numbers and code fragments, like Python's:

Traceback (most recent call last):
  File "<doctest...>", line 10, in <module>
    lumberjack()
  File "<doctest...>", line 4, in lumberjack
    bright_side_of_death()

Then assert might be useable as a function.

@manuel-woelker
Copy link

I did some experiments on this and AFAICT there are the following open issues:

Regarding that last one, any suggestions for a course of action? Is there any good way to get the actual expression inside of a macro? Barring that would fixing quote.rs be a better solution than to_str() in token.rs?

For reference, here is the current POC:

macro_rules! Assert(
    ($inp:expr) => (
        if(!$inp) {
                io::println(fmt!("Assertion '%s' failed, %s:%u", stringify!($inp), file!(), line!()));
            }
    )
)

This gets me as far as: Assertion 'an interpolated expression' failed, assert-poc.rs:52
"Assert" is capitalized, since "assert" is a keyword. Any ideas on how to handle that in the future?

@sanxiyn
Copy link
Member

sanxiyn commented Jan 21, 2013

For "assert is a keyword" issue, see how "fail" is handled in #4524.

@brson
Copy link
Contributor Author

brson commented Mar 30, 2013

Completed by #5628

@brson brson closed this as completed Mar 30, 2013
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Prevent futex_wait from actually waiting if a concurrent waker was executed before us

Fixes rust-lang#2223

Two SC fences were placed in `futex_wake` (after the caller has changed `addr`), and in `futex_wait` (before we read `addr`). This guarantees that `futex_wait` sees the value written to `addr` before the last `futex_wake` call, should one exists, and avoid going into sleep with no one else to wake us up.
https://github.com/rust-lang/miri/blob/ada7b72a879d79aaa06f0a2a95edd520615da1a2/src/concurrency/weak_memory.rs#L324-L326

Earlier I proposed to use `fetch_add(0)` to read the latest value in MO, though this isn't the proper way to do it and breaks aliasing: syscall caller may pass in a `*const` from a `&` and Miri complains about write to a `SharedReadOnly` location, causing this test to fail.
https://github.com/rust-lang/miri/blob/ada7b72a879d79aaa06f0a2a95edd520615da1a2/tests/pass/concurrency/linux-futex.rs#L56-L68
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
…ol only) (rust-lang#2228)

This option will basically override the expected file with Kani's output for every test that fails the expectation. Developers should still prune the expected file to ensure only the information that is needed gets pushed.

My motivation is that I always find myself updating expected tests manually by rerunning Kani for each failure, piping the output to the expected file and edit the file after. With this hack, I only need to do the last step manually.

Since we still fail the test, the files that were updated are listed, which makes it very easy to track down the changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation A-frontend Area: Compiler frontend (errors, parsing and HIR) A-grammar Area: The grammar of Rust E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

7 participants