Turned out that the old code was wrong. I'm not sure why it used to work.
`response.body` properly resolves to an async proc defined in the httpclient
module with the following signature:
proc body*(response: AsyncResponse): Future[string] {.async.}
Perhaps the old code was somehow matching the body field of the `AsyncResponse`
object, which is marked as private.
This commit is a potentially breaking change, but the problem was that
linalg was relying on a previous bug in the compiler, which was fixed
in the concepts branch.
With the old disambiguation rules, generic procs like:
proc \`==\`[T](lhs, rhs: T)
and
proc \`==\`(lhs, rhs: Matrix32|Matrix64)
.. were considered equal, even though it's obvious that the second one
should be preferred. We never noticed this, because there was a bug in
sigmatch incorrectly counting one of the params of the second proc as
a non-generic match, thus giving it an edge.
This commit gives some preference to tyOr and tyAnd during the complex
disambiguation, which may affect overload resolution in other cases.
I see this only as a temporary solution. With my upcoming work on
concept refinement, I plan to provide an experimental implementation
of alaternative C++-like rules for determining which proc is more specific.
We can then discuss our strategy for dealing with such a breaking change.
This fix was necessary in order to fix the lambda lifting used in
the "jsffi" module, which relies on turning nkStmtList into nkLambda
in a catch-all dot operator.
* All JavaScript operators are usable with JsObject
* The dot operators will use native JavaScript strings
* Results returned from dot calls are consired discardable
A more efficient implementation is possible by restoring the old
lifting ot tyGenericInvocation to tyGenericInst in liftTypeParam,
but this fix will suffice for now.
fixes#5087fixes#5602fixes#5641fixes#5570
