You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it was our string interpolators were taking Any values and then
trying to pattern match back their classes to try to show them nicely.
This inevitably fails for things like the opaque type FlagSet, which
interpolates as an indecipherable long number.
Now, instead, they take "Shown" arguments, for which there is an
implicit conversion in scope, given there is a Show instance for value.
I captured some desired results in some new unit test cases.
In the process a small handful of bugs were discovered, the only
particularly bad one was consuming a Iterator when the "transforms"
printer was enabled (accessorDefs), followed by an unintentional
eta-expansion of a method with a defaulted argument (showSummary).
I also lifted out the Showable and exception fallback function as an
extension method, so I could use it more broadly.
The use of WrappedResult and its `result` in `showing` was also
impacted, because the new expected Shown type was driving `result`'s
context lookup. Fortunately I was able to continue to use WrappedResult
and `result` as defined by handling this API change inside `showing`
alone.
I wasn't, however, able to find a solution to the impact the new Shown
expected type was having on the `stripModuleClassSuffix` extension
method, sadly.
JSExportsGen is interpolating a private type, so rather than open its
access or giving it a Show instance I changed the string interpolation.
SyntaxFormatter was no longer used, since the "hl" interpolator was
dropped.
0 commit comments