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

Cannot find assert in $crate::core using [no_std] #55482

Closed
Robbepop opened this issue Oct 29, 2018 · 8 comments · Fixed by #80069
Closed

Cannot find assert in $crate::core using [no_std] #55482

Robbepop opened this issue Oct 29, 2018 · 8 comments · Fixed by #80069
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@Robbepop
Copy link
Contributor

#![no_std]
macro_rules! foo {
    ($e:expr) => {
        $crate::core::assert!($e);
        $crate::core::assert_eq!($e, true);
    };
}
pub fn foo() { foo!(true); }

Compiling the above code generates this error message:

error[E0433]: failed to resolve. Could not find `assert` in `core`
  --> src/lib.rs:5:23
   |
5  |         $crate::core::assert!($e);
   |                       ^^^^^^ Could not find `assert` in `core`
...
13 |     foo!(true);
   |     ----------- in this macro invocation

However, this compiles:

#![no_std]
macro_rules! foo {
    ($e:expr) => {
        assert!($e); // no more `$crate::core::` path prefix!
        $crate::core::assert_eq!($e, true);
    };
}
pub fn foo() { foo!(true); }

Note that for the assert_eq invokation both versions $crate::core::assert_eq! and just assert_eq! works.

Is this intended behaviour or a bug?

Try it yourself at the playground.

@stephaneyfx
Copy link
Contributor

This may be related to the issue where macros (it seems limited to built-in ones) don't work when called qualified with their path. Playground

fn main() {
    // These macros are built into the compiler and calling them qualified
    // with their path does not work:
    //
    // let _ = std::column!();
    // let _ = std::format_args!("blah");
    // let _ = std::concat!("abc", "def");

    // But it works with non built-in macros:
    let _ = std::format!("blah");
    let _ = std::vec![0, 1];
}

@petrochenkov
Copy link
Contributor

assert is not defined in the core library, it's a built-in macro defined by the language.
assert_eq in its turn is indeed defined in core, so it can be used as core::assert_eq!(...).

It should be possible to make a proxy macro assert in core calling built-in assert, it may require some care about what rusdoc shows for that macro though.

@dtolnay dtolnay added the C-bug Category: This is a bug. label Jan 12, 2019
@dtolnay
Copy link
Member

dtolnay commented Jan 12, 2019

This is a bug. The documentation of libcore shows assert being provided by core. I understand that there is nuance around built-in macros but it's clear to me that core::assert! should be accepted.

@steveklabnik steveklabnik added A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. and removed A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools labels Jun 8, 2020
@steveklabnik
Copy link
Member

Triage: the docs of libcore should probably be updated.

@jyn514 jyn514 added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Aug 27, 2020
@jyn514
Copy link
Member

jyn514 commented Nov 4, 2020

Is the request for core::assert! to be accepted or for rustdoc to stop documenting core::assert? If the former, this should be tagged T-libs or T-compiler, not T-rustdoc.

@jyn514
Copy link
Member

jyn514 commented Dec 16, 2020

@dtolnay @steveklabnik you've said contradicting things: @dtolnay said core::assert! should be accepted as-is and @steveklabnik said the docs shouldn't show core::assert! as valid. Which is it? Does it need an RFC?

@jyn514 jyn514 added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 16, 2020
@dtolnay
Copy link
Member

dtolnay commented Dec 16, 2020

$crate::core::assert! needs to work. It does not require an RFC. According to OP, $crate::core::assert_eq! already works.

It's possible there was a rustdoc issue also. According to #55482 (comment), rustdoc was showing assert! in core even though it was not exposed by core in a way that was callable.

@jyn514
Copy link
Member

jyn514 commented Dec 16, 2020

Heh, after all that it turns out this compiles as-is (maybe assert was moved to core recently?). I'll add a test for it.

@jyn514 jyn514 added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Dec 16, 2020
@bors bors closed this as completed in 3cf5bc8 Dec 17, 2020
danielhenrymantilla added a commit to danielhenrymantilla/rust that referenced this issue Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants