Fix FPs around binary expressions in PlatformDependentTruncation
#320
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Under 64-bit toolchains,
PlatformDependentTruncation
currently produces false positives around binary expressions with platform-dependent operands.Example
Nat + 1
has result typeInt64
because theInt64
overload of theAdd
operator intrinsic is selected.<NativeInt> = <Int64>
, and so the rule says "hey,Int64
doesn't fit intoNativeInt
on 32-bit, that will truncate!"Add
operator intrinsic will be selected and the result type will beInteger
- giving us an effective expression of<32-bit NativeInt> = <Integer>
on that toolchain.Solution
Recursively check the operands of binary expression for platform-dependent operands - the whole expression is considered platform-dependent if any of the operands are.
Is this the right solution?
Kind of. It's certainly the right solution for solving this narrowly-scoped problem with binary expressions.
In the grand scheme it's more of a half-measure that covers common cases like
NativeInt + 1
"decaying" toInteger
/Int64
and causing really stupid-looking false positives.There are still holes in this rule's reasoning that we should try to tackle at some stage, but it's non-trivial and would require some solid heuristics - or support for emulating name resolution in a granular way on different toolchains from within rule implementations.
What kind of holes?