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.

Sign up for GitHub

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

Jump to bottom

Provide compile errors from #[ast] macro #124

Open
1 of 3 tasks
overlookmotel opened this issue Aug 6, 2024 · 1 comment
Open
1 of 3 tasks

Provide compile errors from #[ast] macro #124

overlookmotel opened this issue Aug 6, 2024 · 1 comment

Comments

@overlookmotel
Copy link

overlookmotel commented Aug 6, 2024 •
edited by rzvxa
Loading

#[ast] attribute is not meaningful unless the type it's on is in a file which is processed by AST codegen.

Make macro raise an error/panic if the file path needs to be added to AST codegen, with an error that says what to do. This will help people do the right thing.

  • Error on invalid arguments to generate_derive (#4766)
  • Error if fundamental type names such as Span and primitives don't meet our expectations
  • Error on usage of #[ast] attribute on types outside of ast_codegen's view
@overlookmotel overlookmotel mentioned this issue Aug 6, 2024
Merged
@rzvxa rzvxa mentioned this issue Aug 6, 2024
Closed
@overlookmotel overlookmotel mentioned this issue Aug 6, 2024
Merged
rzvxa referenced this issue in oxc-project/oxc Aug 6, 2024
@overlookmotel
refactor(ast_codegen): list input files explicitly (#4708)
654a6e6 
List inputs to the codegen explicitly. This is less DRY, but I think it has the advantage of being more obvious - for #4704.
@rzvxa rzvxa changed the title #[ast] macro raise an error if file it's used in is not processed by AST codegen Provide compile errors from #[ast] macro Aug 8, 2024
@rzvxa rzvxa mentioned this issue Aug 8, 2024
Merged
rzvxa referenced this issue in oxc-project/oxc Aug 8, 2024
@rzvxa
fix(ast_macros): raise compile error on invalid generate_derive inp…
f5eeebd 
…ut. (#4766)

It checks 2 things. 1) The input is a supported derive 2) The given identifier is the same as the fully qualified target trait.

The latter makes sure that the trait for derive is included in the scope.

Part of #4704

Here's an expanded example of how we assert traits:

```rust
const _:() = {
    {
        trait AssertionTrait: ::oxc_allocator::CloneIn<'static> {}
        impl<T: CloneIn<'static>> AssertionTrait for T {}
    };
};
```

It makes sure `CloneIn` is the same as `::oxc_allocator::CloneIn` and more importantly requires the user to include the trait if they wish to use it with `generate_derive`.

It also provides LSP jump to definition.
@rzvxa
Copy link
Collaborator

rzvxa commented Sep 7, 2024

Or... could we prevent the problem you're pointing out by just banning defining/importing types with same names as #[ast] types or other types which appear in AST (e.g. ReferenceId)? That's not quite as satisfying a solution, but would be much simpler than implementing a full resolution algorithm.

Originally posted by @overlookmotel in #107 (comment)

@Boshen Boshen unassigned rzvxa Oct 9, 2024
@Boshen Boshen transferred this issue from oxc-project/oxc Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@overlookmotel @rzvxa