feat(mq-check): support piped builtin calls and self keyword type propagation#1370
feat(mq-check): support piped builtin calls and self keyword type propagation#1370
Conversation
harehare
commented
Mar 2, 2026
harehare
commented
- Fixes type inference for piped builtin calls in argument position (e.g. map(first()))
- Adds support for 'self' keyword to unify with piped input type
- Updates README external tool links
- Adds integration tests for piped builtin calls and self keyword type propagation
…pagation - Fixes type inference for piped builtin calls in argument position (e.g. map(first())) - Adds support for 'self' keyword to unify with piped input type - Updates README external tool links - Adds integration tests for piped builtin calls and self keyword type propagation
There was a problem hiding this comment.
Pull request overview
This PR updates the mq-check type inference engine to better handle piped builtin calls used in argument position (e.g. map(first())) and to propagate the piped input type through a self keyword, alongside small README link updates and new integration tests.
Changes:
- Extend piped-input deferral logic to cover nested calls (to support
map(first())-style higher-order usage). - Add special typing for
selfto unify with the piped input type. - Add integration tests for the above behaviors and update README external tool links.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| crates/mq-check/src/constraint.rs | Adjusts piped-input deferral detection and adds self keyword typing behavior. |
| crates/mq-check/tests/integration_test.rs | Adds integration tests for argument-position piped builtin calls and self propagation. |
| README.md | Updates external tool links (mq-check) and adds mq-lsp entry. |
| if matches!( | ||
| parent.kind, | ||
| SymbolKind::Block | SymbolKind::Function(_) | SymbolKind::Macro(_) | ||
| SymbolKind::Block | SymbolKind::Function(_) | SymbolKind::Macro(_) | SymbolKind::Call |
There was a problem hiding this comment.
Including SymbolKind::Call in might_receive_piped_input makes any nested call defer overload/arity errors (e.g. print(add("x")) could stop reporting "no matching overload" because the inner call’s parent is a Call). This broad deferral looks like a regression; consider narrowing the condition to only the specific scenario you intend (e.g., calls used as higher-order filter arguments with no explicit args), or add a dedicated predicate for that case rather than treating all parent Calls as pipe-capable.
| SymbolKind::Block | SymbolKind::Function(_) | SymbolKind::Macro(_) | SymbolKind::Call | |
| SymbolKind::Block | SymbolKind::Function(_) | SymbolKind::Macro(_) |
