SwiftCompilerSources/SIL: More robust IntegerLiteralInst
construction
#84508
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.
Follow-up to #84052.
ac61901 backfired when building the stdlib on rebranch. This time the problem is reversed: we should be interpreting an integer as unsigned where we no longer do, here:
swift/SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyLoad.swift
Line 78 in 8f7af45
Rather than treating integers as signed by default, make
Builder.createIntegerLiteral
accept a genericFixedWidthInteger
, and manipulate the value based on the generic type argument's signedness.This doesn't entirely define away unintentional sign extensions, but makes this mistake of humouring the parameter type less likely.