[Draft, for discussion only] IDL gen improvements 3 - Fold all proc-macro code back into rs-matter-macros
#239
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(NOTE: #233 and #237 need to go in first or else this PR will show an unrealistically large change-set.)This PR is addressing #236 in folding all of
rs-matter-data-model
,rs-matter-data-model-impl
andrs-matter-macros
into justrs-matter-macros
. The original split was done because of (to my recollection) issues with tests in proc-macro crates.What works in this "folded" setup:
tests
folderWhat does not work:
The "example" which is showing how a user can use the IDL parser - without the
import!
proc-macro - in their code. I don't think that would be a real use case any time soon (if ever) so I just removed thisThe benchmark. We have a single simple benchmark (in the
benches
folder) which is benchmarking (a) the IDL parser parsing time, but is not benchmarking (b) the code-generation time, nor it is benchmarking (c) the time it takesrustc
to actually compile the code generated by theimport!
proc-macro (which is relatively large).I don't have a good answer (not yet at least) how to restore the existing "IDL parser timing" benchmark if we fold all code under the
rs-matter-macros
crate.But in any case, I think we need at some point a more extensive benchmark anyway, which is also timing all three aspects (parsing; code generation; time it takes rustc to compile the generated code). As I have a suspicion that the proc-macro execution time might actually be dominated by (c).