fix(analyser): preserve operand types in augmented assignments 馃攷 - #224
fix(analyser): preserve operand types in augmented assignments 馃攷#224timfennis wants to merge 3 commits into
Conversation
| } | ||
|
|
||
| #[cfg(test)] | ||
| mod tests { |
There was a problem hiding this comment.
Not sure I like these tests
timfennis
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
馃挕 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c90a641f60
鈩癸笍 About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 馃憤.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .multi_cartesian_product(); | ||
| let mut vars = Vec::new(); | ||
| for signature in signatures { | ||
| for var in self.candidates_for_sig(ident, &signature) { |
There was a problem hiding this comment.
When a known operand is Sequence<T>, candidates_for_sig only retains overload parameters subtype-comparable with either Sequence<T> or T; it misses overlapping concrete containers such as List<Any>, even though a Sequence<Int> value may be a List<Int>. Consequently, fn concat(xs: Sequence<Int>, rhs) => xs ++ rhs; concat([1], ([2], [3])) is now rejected during analysis, although at runtime the list can be broadcast across the unknown tuple and the List ++ List overload accepts each element. The previous permissive fallback included this valid candidate, so the new filtering should account for overlapping sequence-family types while still excluding genuinely incompatible scalar overloads.
Useful? React with 馃憤聽/ 馃憥.
1 participant
An unknown right operand could make scalar augmented assignments fail with a type mismatch:
fn opaque(x) => x; let ok = false; ok |= opaque(true);was rejected even though Boolean|supports the runtime values. Unannotated recursive Boolean calls encountered the same error.Vector fallback erased every operand type when any argument was
Any, admitting map/set mutation overloads for known Boolean and integer operands. It now retains those constraints while considering tuple elements forSequence<T>arguments. Scalar assignments and valid vector operations succeed; incompatible list and map mutations remain rejected.For rejected container mutations, CLI diagnostics label both operands, and LSP diagnostics highlight the right operand with a related location for the target. Target spans include grouping and index delimiters.
Replace analyser tests with invented operator signatures with
.ndcprograms using the real standard library. LSP diagnostic tests use a concreteList<Int> ++= List<Float>mismatch. Remove recursion-specific annotation advice.Validation:
cargo test --workspace --locked: 657 passed, 3 ignored (including doctests).cargo build --no-default-features --locked.cargo fmt --all --checkandgit diff --check.+=,-=,|=,&=, and~=, recursive calls, tuple values behindAnyandSequence<Int>, assignment widening, container rejection, and LSP ranges including UTF-16 positions.AI disclosure: Codex generated the implementation, tests, and PR description.