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

extract codegen into macro-rules macros #185

Merged
merged 18 commits into from
Oct 1, 2024

Conversation

nikomatsakis
Copy link
Member

@nikomatsakis nikomatsakis commented Sep 30, 2024

This applies a pattern that I've found to be very nice to work with, in which the duchess crate has two helper crates:

  • duchess-macro-rules, internal macro_rules! macro that handle most of the codegen
  • duchess-macros, procedural macros which generate calls to those macros after doing validation and pre-processing

This combo lets each kind of macro manage the things it is good at: procedural macros for generating errors and doing some grody stuff, but macro-rules for generating the actual code.

Also, as a driveby change, adds a dev-container.json file which makes it easier to manage the setup for testing and developing.

r? @rcoh

nikomatsakis and others added 16 commits September 19, 2024 18:01
The procedural macro now generates a call to
`setup_class!` which generates the actual code.
We used to process types in many ways and pass
in a number of various. We now generate most of
those in declarative macro-rules logic in
`java_types.rs` so that we can just pass in
token tree description of the java type and
let the rest of the code work.
This lets us avoid the grodiness of having
to pass in the self identifier.
@rcoh rcoh self-requested a review September 30, 2024 19:09
Copy link
Contributor

@rcoh rcoh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely a big improvement in terms of readability of the codegen.

In the long term, having some tests of the macros directly is probably a reasonable thing to add—I think it will make working on the macros easier.

There is some dead (and I think? incorrect) code in macro_if that we should remove before merging. But otherwise this looks good.

macro-rules/src/java_types.rs Outdated Show resolved Hide resolved
macro-rules/src/lib.rs Show resolved Hide resolved
Comment on lines 7 to 9
(if [$($input:tt)+] { $($then:tt)* }) => {
$($then)*
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm kinda confused, but this looks like it ignores the $input arguments? AFAICT it expands identically to if true

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah—I think actually all of these expect the last two are dead code

macro-rules/src/util.rs Outdated Show resolved Hide resolved
duchess-reflect/src/codegen.rs Show resolved Hide resolved
macro-rules/src/util.rs Outdated Show resolved Hide resolved
@@ -68,6 +68,12 @@ pub mod plumbing {
pub use crate::raw::{EnvPtr, FieldPtr, FromJniValue, IntoJniValue, MethodPtr, ObjectPtr};
pub use crate::refs::NullJRef;
pub use crate::to_java::{ToJavaImpl, ToJavaScalar};
pub use duchess_macro_rules::{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should make the whole plumbing module doc(hidden)

Copy link
Member Author

@nikomatsakis nikomatsakis Oct 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I've been thinking we should also rename it to semver_unstable or something more explicit.

@nikomatsakis
Copy link
Member Author

I'm of mixed minds about unit tests on the macros themselves — they don't represent a stable API boundary and I'm generally not in favor of tests that don't target a stable API boundary, since they can become dated so easily when refactorings occur. On the other hand, I know they can have value in making it easy to specify edge cases.

@nikomatsakis
Copy link
Member Author

Thanks for the review, @rcoh, I'll go over the docs and make a few improvements and then merge.

Niko Matsakis added 2 commits October 1, 2024 14:52
@nikomatsakis
Copy link
Member Author

Made cosmetic improvements. Will merge once CI is green.

@nikomatsakis nikomatsakis merged commit 0a81378 into duchess-rs:main Oct 1, 2024
13 checks passed
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.

2 participants