Conversation
- Don't expand parameter bounds first and then substitute the actual arguments. This leads to error messages with unnecessary casts in them. - Suppress printing duplicate errors for the same modifying expression used multiple times in a bounds expression.
sulekhark
pushed a commit
that referenced
this pull request
Jul 8, 2021
* change assert to consistency fail(macro) * remove checked regions around inconsistent function calls; fix logic error * add macro check * don't add type params if they're all inconsistant * add test * remove commented code * allow existing macro type params to be valid * minor efficientcy * use more appropriate rewrite check
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bounds expressions aren't allowed to contain modifying expressions. It is possible for bounds inference to create bounds expressions containing modifying expressions when inferring bounds expressions for member operator expressions.
We have code that attempts to disallow the creation of invalid bounds expressions by making the bounds be unknown. This code is wrong because it can cause the compiler to skip checking bounds declarations when the inferred target bounds for the LHS of an assignment contains a modifying expression.
Instead of trying to hack the results of the inference analysis, cast a wide net by directly checking that bounds expressions created by bounds inference are non-modifying expressions. This directly prevents the creation of bounds checks with side-effects embedded in them and incorrect analysis of bounds expressions with side effects.
Testing: