Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate using type aliases instead of unit structs when comparing explicit vs inferred types #31

Open
AzureMarker opened this issue Jan 2, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@AzureMarker
Copy link
Owner

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:

// alternative type resolves to std::collections::HashMap<K, V>
MyNonterminal<K, V>: HashMap<K, V> = ...;

Current behavior:

// imports

struct K;
struct V;

type T1 = HashMap<K, V>;
type T2 = std::collections::HashMap<K, V>;

Proposed behavior:

// imports

type T1<K, V> = HashMap<K, V>;
type T2<K, V> = std::collections::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.

@AzureMarker AzureMarker added the enhancement New feature or request label Feb 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant