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

Allow = and multiline prefix/postfix in annotations #863

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

novafacing
Copy link
Contributor

@novafacing novafacing commented Jul 31, 2023

This adds two things:

  1. = is allowed in annotations. Previously, it was an error to have an = in the annotation but I'm doing hacky stuff (see below) and it didn't seem like there was a good reason not to permit it.
  2. Multiline annotations are now supported by using a \ at the end of the annotated line and any following lines that should be concatenated together with newlines.

What this allows is basically:

#[cfg(target_arch = "i386")]
pub mod foo {
  #[no_mangle]
  /// cbindgen:prefix= \
  /// #define FUNC_THAT_NEEDS_TO_BE_IFDEFED(x) \ \
  ///     do { \ \
  ///         do_something(x); \ \
  ///    } while (0) \
  ///
  pub extern "C" fn bar() {}
}

Note the \ \: the last \ becomes a newline, then the line is trimmed and appended to the
annotation value. This means if you want a literal \ in your code (as you frequently do in a macro), you need two \.

after_include is useful, but it has trouble when you need to conditionally compile based on the ifdef generated for a cfg attribute. This fixes that and makes it possible to somewhat hackily embed arbitrary C code wherever you want (at the cost of having to declare something). Eventually an annotation that can occur on a free comment might be nice to eliminate this need, but the two changes added by this PR, the = allowing and multiline allowing would still be needed.

@novafacing
Copy link
Contributor Author

Whoops, looks like I failed the MSRV check. Will fix that.

@novafacing
Copy link
Contributor Author

Hmm, the clippy error is a false positive...I'll see what I can do.

@emilio
Copy link
Collaborator

emilio commented Sep 4, 2023

At the very least this needs a test. Not opposed to this in principle tho?

@novafacing
Copy link
Contributor Author

Yeah it's breaking a lot of existing comments, I want to rework it and use some less silly parsing!

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

Successfully merging this pull request may close these issues.

None yet

2 participants