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

Omnimacro2 #12

Merged
merged 40 commits into from
Aug 2, 2019
Merged

Omnimacro2 #12

merged 40 commits into from
Aug 2, 2019

Conversation

asomers
Copy link
Owner

@asomers asomers commented Aug 2, 2019

A major refactor that eliminates all traditional macros, by merging them with the proc macros. The main benefit is that generic static methods with generic bounds are now supported.

asomers added 30 commits July 14, 2019 21:11
After the omnimacro2 conversion is complete, mock! and automock!'s
output will be too long for practical unit testing.

Found bugs that need attention regarding:

* methods that return impl Trait, for non-builtin traits
* method arguments with 'static lifetimes
It's nearly impossible for ordinary macros to handle generic bounds and
where clauses.  So I have to rewrite the crate, AGAIN.  This branch will
move most of mockall's macros (all of them that deal with generics) into
mockall_derive.
This BREAKS the old expectation! macro
Now nothing in mockall_derive is still using expectation!
…rams

Apparently regular macros always add trailing punctuation when expanding
a list, and that matters because any::TypeID::of::<(T)>() is different
than any::TypeID::of::<(T,)>().  So until the regular macros are gone,
the proc macro will need to add matching trailing punctuation.
Use more of syn's types directly, just to reduce pathnames in the code
This test doesn't provide any coverage that the mockall_derive tests
don't.
Split mockall_dervive's integration tests into separate files, and move
them into mockall's test directory.  This serves two purposes:

1) proc macro failures are much easier to debug, because the compiler's
error output (and MOCKALL_DEBUG output) is limited to a single test case
at a time.  Prior to this change, I had to debug proc macro failures by
commenting out all test cases but one in a file.

2) The omnimacro2 rewrite is breaking down the barriers between the
mockall and mockall_derive crates.  This change is the first step in
reorganizing test cases accordingly.  Next I'll merge mockall's old
integration tests into the new files, and then there will be no more
integration tests for mockall's plain macros.
expectation! is no more
Now all integration tests use either mock! or automock!
Times.never() didn't work, because of an integer subtraction overflow
error in is_done.  Fix by using 0..1 as the default empty range rather
than 0..0.

Fixes #10
If the interface being mocked has a new method, then mockall is not
supposed to automatically generate one. That worked fine for structs, but
it didn't for traits.

Fixes #3
asomers added 10 commits August 1, 2019 11:53
This regression was introduced by moving expectation! into the proc
macros.
This will allow the code to be simplified, and eventually allow for
things like where clauses in constructor methods.
proc macros don't have the same hygiene guarantees as normal macros, so
it's now possible for a variable declared locally in the proc macro to
conflict with a mocked method's argument name.  Forestall this
possibility by minimizing the number of named local variables and by
prefixing any necessary local variables with "__"
Mocking a constructor method for a generic struct requires the method's
mock code to keep track of the struct's generic bounds.  That wasn't
possible when using ordinary macros, because it's nearly impossible for
an ordinary macro to match generic bound lists.

By removing the "macro_g" list of idents that formerly got passed around
everywhere, structs' generic bounds are now properly tracked.  Now all
methods use a &Generics argument.

Fixes #11
This was broken by the omnimacro2 branch, when it converted the old
regular macros to proc macro code.
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.

1 participant