You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the WrongInferredTypeInspection uses unit structs in place of the generic types when comparing the explicit (written by the user in the lalrpop file) and inferred (via the plugin code) types of a nonterminal.
Example nonterminal:
// alternative type resolves to std::collections::HashMap<K, V>
MyNonterminal<K, V>: HashMap<K, V> = ...;
The current behavior fails when the type has restrictions on the generics it allows. For example if HashMap always requires Hash for the first generic this might fail (but this hasn't really been tested). The proposed behavior is more intuitive, as Rust type aliases are designed to not care about the type restrictions on the generics, but is trickier to implement.
In the second related discussion @dblanovschi points out some possible issues with the proposed behavior, such as the difficulty in getting an intellij-rust Substitution object to compare the types with. The proposed method is promising, but requires some more investigation before we know if it's possible and what the tradeoffs are.
The text was updated successfully, but these errors were encountered:
Related discussions:
Currently the
WrongInferredTypeInspection
uses unit structs in place of the generic types when comparing the explicit (written by the user in the lalrpop file) and inferred (via the plugin code) types of a nonterminal.Example nonterminal:
Current behavior:
Proposed behavior:
The current behavior fails when the type has restrictions on the generics it allows. For example if
HashMap
always requiresHash
for the first generic this might fail (but this hasn't really been tested). The proposed behavior is more intuitive, as Rust type aliases are designed to not care about the type restrictions on the generics, but is trickier to implement.In the second related discussion @dblanovschi points out some possible issues with the proposed behavior, such as the difficulty in getting an intellij-rust
Substitution
object to compare the types with. The proposed method is promising, but requires some more investigation before we know if it's possible and what the tradeoffs are.The text was updated successfully, but these errors were encountered: