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

Consider a different syntax for provider and name #4

Open
cuviper opened this issue Jul 9, 2014 · 1 comment
Open

Consider a different syntax for provider and name #4

cuviper opened this issue Jul 9, 2014 · 1 comment

Comments

@cuviper
Copy link
Owner

cuviper commented Jul 9, 2014

The current syntax is:

probe!(provider, name)
probe!(provider, name, arg1, ...)

A few people in the Rust PR and on Reddit mentioned that the provider and name are a little confusing. They both need to follow identifier rules, but they don't actually relate to any value in the surrounding code. Compare that to the arguments which do have to be valid expressions.

It's pretty trivial to tweak this, but I want to be sure I'm actually making it better first. The best option I've thought of so far, with some similarity to how tools use them, is to separate provider and name with a colon, like:

probe!(provider : name)
probe!(provider : name, arg1, ...)

This way they still look like bare identifiers, but there's a visual cue that something unusual is going on.

@jonhoo
Copy link

jonhoo commented Mar 5, 2019

I ran into a similar issue in rust-lang/rfcs#875 (comment). This manifests particularly in eBPF where the provider name is expected to match the name of the binary (bpftrace/bpftrace#328 (comment)). That's sort of hard when binaries often contain -, whereas Rust identifiers aren't allowed to. There are ways to work around that (bpftrace/bpftrace#413), but it'd be nicer if we could just directly specify the appropriate provider name.

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

No branches or pull requests

2 participants