ndmitchell / ndmitchell/hlint

Too lenient matches against qualified names

Open
#164 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

scope
Dominant language
Haskell
Stars
1.6k
Forks
210
PR merge metrics
No merged PRs in 30d

Description

From https://code.google.com/p/ndmitchell/issues/detail?id=445:

Given the rule:

error = Legacy.foo ==> Current.foo

And the program:

import Legacy(Foo(..))
import Current
main = foo

You currently get a warning about using Legacy.foo. The resolution engine determines that foo /may/ be equivalent to Legacy.foo (the best it can do without knowledge of imports). However, this warning should really only be given if the resolution can determine for certain that foo /is/ equivalent to Legacy.foo (if the code type checks). For example if it had any of the following imports:

import Legacy
import Legacy(foo)
import Legacy hiding (bar)

There's a possibility that there should be a weaker form of matching as well, when you want the match even if it may be equivalent.

Alternatively, if you had a way to say that foo was a member of the constructor/type Foo then you could resolve unambiguously.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the resolution engine that compares rule names with qualified names. Use the import examples in the issue to trace when equivalence is certain versus merely possible; done means the Legacy.foo warning is emitted only for certain matches, while the proposed weaker matching remains an explicit design question.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
tooling
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.