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

Fix Scheme! macro to be used from other crates #68

Open
wants to merge 197 commits into
base: cloudflare
Choose a base branch
from

Conversation

sbohrer
Copy link

@sbohrer sbohrer commented Sep 16, 2020

The Scheme! macro references crate, but since it is a macro this
will evaluate at compile time to be the crate that is attempting to use
wirefilter. We must use $crate to force the lookup to occur in the
crate defining the macro.

marmeladema and others added 30 commits May 14, 2019 11:48
This was deleted when working on the Map & Array data types.
See e500dc1 for more info.

Before this commit `TypeMismatchError` was expecting fully qualified
`Type` for the expected `member`. However when executing `Map::try_form`
we only know that we expect a Map but not a Map of which specific type
(same apply for Array). To overcome this issue, i thought about two
different solution:
* Implement custom `try_from(ty: Type)` method for Map and Array
  without implementing the TryFrom trait itself (because the prototype
  of try_from does not expect any argument)
* Modify the `TypeMismatchError` type to be able to express that
  lack of knowledge.

I chose the later:
* ExpectedMismatchType::Type(Type) corresponds to a fully qualified
  expected type
* ExpectedMismatchType::Array is used when expected an Array bot not
  knowing of which Type
* ExpectedMismatchType::Map is used when expected a Map bot not
  knowing of which Type
Scheme now stores trait object that implements the FunctionDefinition
trait instead of bare Function object.
Before one could return a max_arg_count lower than min_arg_count.
* Return error directly from check_param in FunctionDefinition trait

* Store a set of expected types in TypeMismatchError
inikulin and others added 29 commits September 16, 2020 17:49
The `Scheme!` macro references `crate`, but since it is a macro this
will evaluate at compile time to be the crate that is attempting to use
wirefilter.  We must use `$crate` to force the lookup to occur in the
crate defining the macro.
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

9 participants