-
Notifications
You must be signed in to change notification settings - Fork 39
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
std/json
: remove macro type API usage
#825
std/json
: remove macro type API usage
#825
Conversation
`containsNode` previously attempted to traverse `nkError` nodes, resulting in run time error as there is no child nodes field (`sons`).
little ugly, but this is the first pass proving it out for `object` and `tuple` types.
…-macro-type-api-usage
|
…-macro-type-api-usage
will remove the `tjsonmacro_reject` test
std/json
: remove macro type API usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! It's a lot less code now, and the version using generics is much easier to understand too. I've left a few clean-up suggestions.
As an aside, the removal of nimFixedForwardGeneric
makes the final change-set a bit hard to read. Turning the removal into a separate PR would be nice, but it's not something blocking -- no change expected from my side here.
@@ -986,7 +984,7 @@ proc skipGenericInvocation(t: PType): PType {.inline.} = | |||
|
|||
proc addInheritedFields(c: PContext, check: var IntSet, pos: var int, | |||
obj: PType) = | |||
assert obj.kind == tyObject | |||
assert obj.kind == tyObject, $obj.kind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assert obj.kind == tyObject, $obj.kind | |
assert obj.kind == tyObject |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it be easier to debug by leaving the kind in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would, although I personally think that assertions with $x
are visually a bit noisy, hence my suggestion. It's nothing critical, however, and I'm fine with it staying as it is.
It's nothing for this PR, but since asserting that the discriminator of some object has a certain value is a common pattern in the compiler, I think that adding a new idiom assertKind
(which automatically renders the value on failure) would make sense.
I've applied some small typo and grammar fixes to the PR message. |
Co-authored-by: zerbina <100542850+zerbina@users.noreply.github.com>
Co-authored-by: zerbina <100542850+zerbina@users.noreply.github.com>
Co-authored-by: zerbina <100542850+zerbina@users.noreply.github.com>
Co-authored-by: zerbina <100542850+zerbina@users.noreply.github.com>
/merge |
Merge requested by: @saem Contents after the first section break of the PR description has been removed and preserved below:
|
Summary
Remove usage of
macros
type API usage instd/json
, specificallygetTypeImpl
andgetTypeInst
. This is part of a broader effort todrop this API from the standard library. The current API enforces a
number of poor design decisions in compiler internals. The API itself
is questionable and much of this work should happen via generics.
Details
As part of removing the usage of these APIs, there was a slight
regression in the precision of errors when a tuple without named fields
is used. The error message is equivalent, but the error location will
be within the
json
module itself.The change itself uses the
fieldPairs
iterator which relies uponcompiler support in
semfields
. Some minor adjustments were made herein particular the ability to handle
nkError
nodes.The
json
module relies upon the ability to forward declare genericprocedures, this was not possible with the earlier bootstrap compilers,
and existed behind a conditional compilation flag
(
nimFixedForwardGeneric
). Seeing as this is no longer the case theflag has been removed as part of the module rework.
Finally, the test
tjsonmacro_reject
existed for the previous approach,but the test are combined into
tjsonmacro
and the previous test isremoved.