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

FunctionDefinition.has_named_attribute(quote {test}) returns false for test functions #6009

Closed
Thunkar opened this issue Sep 12, 2024 · 4 comments · Fixed by #6024
Closed
Assignees
Labels
bug Something isn't working

Comments

@Thunkar
Copy link
Contributor

Thunkar commented Sep 12, 2024

Aim

I want to be able to filter out test functions when iterating through a module.

Expected Behavior

FunctionDefinition.has_named_attribute(quote {test}) returns true for #[test] functions, or an extra .is_test() helper is added.

Bug

FunctionDefinition.has_named_attribute(quote {test}) for a test function returns false.

To Reproduce

Workaround

None

Workaround Description

No response

Additional Context

No response

Project Impact

None

Blocker Context

No response

Nargo Version

No response

NoirJS Version

No response

Proving Backend Tooling & Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@Thunkar Thunkar added the bug Something isn't working label Sep 12, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Sep 12, 2024
@asterite
Copy link
Collaborator

So, the idea of has_named_attribute is that it only checks against custom attributes. I wonder whether we should add an is_test() as you suggested... or maybe we can have has_named_attribute also check the built-in attributes (I think I'll do this).

I also wonder if has_named_attribute should take a str<N> instead of Quoted, what do you think?

@Thunkar
Copy link
Contributor Author

Thunkar commented Sep 12, 2024

I also wonder if has_named_attribute should take a str instead of Quoted, what do you think?

It definitely feels weird to provide a quoted value since right now attributes are more or less "free form", so a string feels more natural. IDK if it might affect something in the future, I'm fine with both!

@jfecher
Copy link
Contributor

jfecher commented Sep 12, 2024

I'd be fine if the string just matched against the name but we should 100% avoid it matching against arguments as well. It works for a single word but we don't want to worry about spacing being different in the annotation or anything like that.

github-merge-queue bot pushed a commit that referenced this issue Sep 12, 2024
# Description

## Problem

Resolves #6009

## Summary

Also made it a bit more efficient.

## Additional Context

## Documentation

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Sep 12, 2024
@asterite
Copy link
Collaborator

I'd be fine if the string just matched against the name but we should 100% avoid it matching against arguments as well. It works for a single word but we don't want to worry about spacing being different in the annotation or anything like that.

What if we lexed both the argument and the attribute and check that the tokens match? That way spacing being different wouldn't be an issue.

I'm still not sure about it, though. I'm just wondering what's the best way to check if something is annotated with #[aztec(public)] if we don't want to change that to #[aztec_public].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants