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

Sanitize rust macros to avoid forcing user's environment #298

Closed
clembu opened this issue Jul 17, 2023 · 0 comments · Fixed by #299
Closed

Sanitize rust macros to avoid forcing user's environment #298

clembu opened this issue Jul 17, 2023 · 0 comments · Fixed by #299

Comments

@clembu
Copy link

clembu commented Jul 17, 2023

Problem to Solve

Currently the builder macros rely on a particular lexical environment.
For example

typeql_lang::typeql_define()
// will expand to
TypeQLDefine::new(vec![])

requiring the user to have TypeQLDefine in the lexical environment.

This is a problem because it lets users do this sort of thing:

struct TypeQLDefine;
impl TypeQLDefine {
  fn new(Vec<typeql_lang::pattern::Definable>) -> Self { Self }
}

// somewhere where that TypeQLDefine is in scope...
typeql_define!(my_type, my_rule) // <-- this line doesn't error

This is a minimal example, but you can see where major problems can arise.

Proposed Solution

Using proper rust macro hygiene fixes this issue, by expanding to fully qualified identifiers.

To fix the define query, for example, is as simple as replacing it with

#[macro_export]
macro_rules! typeql_define {
    ($($pattern:expr),* $(,)?) => {{
        $crate::query::TypeQLDefine::new(vec![$($pattern.into()),*])
    }}
}

With this we have

typeql_define!()
// will expand to
typeql_lang::query::TypeQLDefine::new(vec![])

Read more on macro hygiene at: https://veykril.github.io/tlborm/decl-macros/minutiae/hygiene.html

@dmitrii-ubskii dmitrii-ubskii self-assigned this Jul 17, 2023
dmikhalin added a commit that referenced this issue Jul 19, 2023
## What is the goal of this PR?

The problem is described in #298: we have macros that need access to other
items in our crate. Paths to these items were not absolute, and users
had to import that particular items and were able to use their own
objects with the same names and use it in the macros. Now all paths are
absolute, based on the `$crate` metavariable.

## What are the changes implemented in this PR?

- We updated all macros that need access to other items in the crate.
- We removed redundant imports. 

closes #298
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants