Skip to content

Unresolved import for declarative macros 2.0 #6059

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

Closed
fmease opened this issue Sep 22, 2020 · 6 comments
Closed

Unresolved import for declarative macros 2.0 #6059

fmease opened this issue Sep 22, 2020 · 6 comments
Labels
A-macro macro expansion E-unknown It's unclear if the issue is E-hard or E-easy without digging in S-actionable Someone could pick this issue up and work on it right now

Comments

@fmease
Copy link
Member

fmease commented Sep 22, 2020

Since #6016. Importing a declarative macro 2.0 (an experimental feature) is falsely flagged as unresolved.

Minimal example to reproduce:

#![feature(decl_macro)]

use foo as _; // error: unresolved import
macro foo() {}

fn main() {}

If I am not mistaken, RA itself already handles declarative macros 2.0 in some places and it is in fact not rustc which resolves them:

#![feature(decl_macro)]

foo!(); // RA's name resolver can handle this
macro foo() {}

fn main() {}
@fmease

This comment has been minimized.

@jonas-schievink
Copy link
Contributor

Yeah we don't support them at the moment. We have some hacks in place so that builtin macros from the standard library still work.

@jonas-schievink jonas-schievink added the A-macro macro expansion label Sep 23, 2020
@fmease
Copy link
Member Author

fmease commented Sep 23, 2020

If I may ask, do you think there is enough information in the code base already that improving support is relatively easy? Is it even acceptable to implement for RA given it's an unstable/experimental feature?

At first glance, it seems like ModCollector::collect is the place to start, am I correct? Extending it to handle a new ModItem::Macro and going from there.

@jonas-schievink
Copy link
Contributor

Yeah it should be fine to add support for them

@fmease
Copy link
Member Author

fmease commented Sep 24, 2020

FYI, the overarching issue is #2248. However in my opinion, this issue (#6059) should not be closed in favor of the other one since it is specifically about error messages which should not be reported and which weren't reported before.

@matklad matklad added E-unknown It's unclear if the issue is E-hard or E-easy without digging in S-actionable Someone could pick this issue up and work on it right now labels Oct 14, 2020
@matklad
Copy link
Member

matklad commented Apr 27, 2021

works on master

@matklad matklad closed this as completed Apr 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macro macro expansion E-unknown It's unclear if the issue is E-hard or E-easy without digging in S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

3 participants