| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
@kares I think you should give it a try (make it just fully overwrite the flags) and we'll check with @enebo as to why he wrote this to preserve the empty flag. I suspect it was either not intentional or served a purpose that no longer exists. |
Sorry, something went wrong.
kwargs could still be kept -> polluting next call-site
| isLambda = (callInfo & ThreadContext.CALL_KEYWORD) != 0 ? | ||
| lambdaOpt.isTrue() : | ||
| isLambda(); | ||
| isLambda = hasKeywords(callInfo) ? lambdaOpt.isTrue() : isLambda(); |
There was a problem hiding this comment.
This could be simplified to:
var isLambda = !lambdaOpt.isNice` && hasKeywords(callInfo) ?
lambdaOpt.isTrue() :
isLambda();
Sorry, something went wrong.
There was a problem hiding this comment.
I realize this is merged. Just noticed the logic could be simplified.
Sorry, something went wrong.
|
As a comment for posterity. I think passing callInfo as a value in the two places which introduced the extra passing is baking callInfo into the API which was not a goal of callInfo (it was meant to be a temporary workaround for not changing all call code paths). That said, those two places are private and can be backed out simply when a longer term solution comes along. So I was ok with this PR but just thought it is worth mentioning somewhere that the goal was to minimally affect API call paths with callInfo as a value. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
trying to get the keywords = true aligned with proper resetCallInfo, where it's needed (follow-up on #9285).
on some places this won't trigger an issue unless something changes in the method (would be easy to miss).
but there also are places where ArgumentError reproduces easily (similar to #9281) e.g.
the above isn't completely fixed due being quite specific and reveals an issue with IRRuntimeHelper.setCallInfo which retains the empty flag:
think that should only be used in specific circumstances as the retaining causes issues (such as above).
not 100% why it's kept (esp. the JIT parts) yet and whether simply changing to context.callInfo = flags would not cause more harm for now this is not needed, the above bug was resolved.