Skip to content

Exportable macros require hardcoding crate's name #12088

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
huonw opened this issue Feb 7, 2014 · 6 comments
Closed

Exportable macros require hardcoding crate's name #12088

huonw opened this issue Feb 7, 2014 · 6 comments
Labels
A-syntaxext Area: Syntax extensions

Comments

@huonw
Copy link
Member

huonw commented Feb 7, 2014

which means the user has to import it under that name to use the macros.

// some_crate.rs
#[feature(macro_rules)];

pub static X: uint = 1;

#[macro_export]
macro_rules! foo { () => { some_crate::X } }
// other_crate.rs
#[feature(phases)];
#[phase(syntax, link)] extern mod blah = "some_crate";

fn main() { foo!(); } // unresolved name some_crate
@sfackler
Copy link
Member

sfackler commented Feb 7, 2014

The solution I've been using is to document that certain things have to be imported from the crate when a macro is used. A better solution would be nice, but would probably require a lot of infrastructure.

@huonw
Copy link
Member Author

huonw commented Feb 8, 2014

I guess that works too, but it also requires that those things are imported under some specific name.

@huonw
Copy link
Member Author

huonw commented Nov 21, 2014

cc @kmcallister, #17103

@kmcallister
Copy link
Contributor

Yeah, $crate would fix this.

@jonas-schievink
Copy link
Contributor

This looks pretty fixed now

@sfackler
Copy link
Member

sfackler commented Oct 3, 2015

Yep, has been fixed for a while.

@sfackler sfackler closed this as completed Oct 3, 2015
flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 11, 2024
…int-listing, r=Manishearth

fix: metadata-collector lists wrong affected lints

fixes rust-lang#12042

This PR addresses the issue where the `metadata collector` incorrectly generates the `Affected Lints` section when a comma is included in the configuration documentation.

I made adjustments; however, if the `/// Lint: SOMETHING` section ends with `.` it always produces the correct output.
For example,
```rust
/// Lint: PUB_UNDERSCORE_FIELDS
```
should be
```rust
/// Lint: PUB_UNDERSCORE_FIELDS.
```

changelog: none
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-syntaxext Area: Syntax extensions
Projects
None yet
Development

No branches or pull requests

4 participants