Incorrect error/warning position ranges

@paf31

I'm working on a frontend for psc that prints original source ranges, so it makes it very easy to spot which errors have incorrect position reporting. This issue is to catalog all those we find so we don't have to make separate issues for them.

Edit (@paf31) Here is a list of all errors listed here. Let's check them off as they get fixed:

ShadowedName

If you do something like

foo = \baz ->
  case baz of
    Just baz -> 42
    Nothing  -> 12

It returns the position of the entire top level expression, which can require some hunting. It should point to where the shadowed name was bound.

Also, interestingly, if I change it to:

foo' baz = case baz of
  Just baz -> 42
  Nothing  -> 12

No warning is generated.

WildcardInferredType

The position ranges over the entire type declaration. It should point to a specific wildcard, otherwise its confusing if you have multiple wildcards.

UnknownValue

Given:

module Test.Foo where

foo n = n + 1

It reports the error as

Error found:
in module Test.Foo
at /Users/nathan/Sites/purescript/purescript-psa/test/Foo.purs line 3, column 9 - line 3, column 13

  Unknown value (+)

The correct start range would be line 3, column 11.

ErrorParsingModule

Given:

module Test.Foo where

improt Prelude
import Bar

It reports the error as

Error found:
at /Users/nathan/Sites/purescript/purescript-psa/test/Foo.purs line 4, column 1 - line 4, column 1

  Unable to parse module:
  unexpected "import"
  expecting binder or indentation

Which is an empty span.

NoInstanceFound

module Test where
import Prelude

type Foo = {foo::Int}
foo :: Foo -> Foo -> Boolean
foo x y = x == y

Error found:
in module Test
at Test.purs line 5, column 1 - line 6, column 1

  No type class instance was found for

    Prelude.Eq { foo :: Int
               }


in value declaration foo


See https://github.com/purescript/purescript/wiki/Error-Code-NoInstanceFound for more information,
or to contribute content related to this error.

InfiniteType

module InfiniteType where
import Prelude (map)

foo = "wat"
  where
  woo = "woo"
  wat x = map (\k -> wat k x)

  in module InfiniteType
  at InfiniteType.purs line 6, column 3 - line 7, column 3

    An infinite type was inferred for an expression:

      _0 _1


  while trying to match type _0 _1
    with type _1
  while inferring the type of let
                                woo = "woo"
                                wat = \x ->
                                        ...
                              in "wat"
  in value declaration foo

  where _0 is an unknown type
        _1 is an unknown type

Which is the definition of woo (it's wat that gives the error). If you do this at the top level it reports no error location.

CannotDerive
doesn't have position

derive instance foo :: Generic {foo::Int}

Error found:

  Cannot derive a type class instance for

    Data.Generic.Generic { foo :: Int
                         }




See https://github.com/purescript/purescript/wiki/Error-Code-CannotDerive for more information,
or to contribute content related to this error.

DuplicateModuleName
doesn't have position
Main.purs

module Main where

Main2.purs

module Main where

Error found:

  Module Main has been defined multiple times.



See https://github.com/purescript/purescript/wiki/Error-Code-DuplicateModuleName for more information,
or to contribute content related to this error.

CycleInModules
doesn't have position
Main.purs

module Main where
import Test

Test.purs

module Test where
import Main

Error found:

  There is a cycle in module dependencies in these modules:

    Main
    Test




See https://github.com/purescript/purescript/wiki/Error-Code-CycleInModules for more information,
or to contribute content related to this error.

UnknownImportDataConstructor
doesn't have position

module Test where

type Foo = Foo Int

Error found:
in module Test

  Module Test does not export data constructor Foo for type Foo



See https://github.com/purescript/purescript/wiki/Error-Code-UnknownImportDataConstructor for more information,
or to contribute content related to this error.

TypesDoNotUnify

If the return type of a do block is incorrect, the error spans over the entire block.

module DoTest where

import Prelude
import Data.Maybe

foo :: Maybe String
foo = do
  x <- Just 42
  y <- Just 12
  pure y

[1/1 TypesDoNotUnify] src/DoError.purs:7:7

            v
   7  foo = do
   8    x <- Just 42
   9    y <- Just 12
  10    pure y
           ^

  Could not match type

    Int

  with type

    String

  while trying to match type Maybe _0
    with type Maybe String
  while checking that expression (bind (Just 42)) (\$1 ->
                                                     case $1 of
                                                       x -> ...
                                                  )
    has type Maybe String
  in value declaration foo

  where _0 is an unknown type

UnknownDataConstructor

module Test  where

data Foo = Foo Int
foo = Foo Bar

Error found:
in module Test
at Test.purs line 4, column 7 - line 4, column 11

  Unknown data constructor Bar


See https://github.com/purescript/purescript/wiki/Error-Code-UnknownDataConstructor for more information,
or to contribute content related to this error.

should be line 4, column 11 - line 4, column 13

WildcardInferredType is done (also listed twice above)

  7  main :: forall eff. Eff (console :: CONSOLE | eff ) _
                                                         ^

UnknownName - it seems this example has a different error code but the same error position (note the same occurs with foo n = add n 1, the wording is different)

[1/1 UnknownName] src/Foo.purs:10:9

  10  foo n = n + 1
              ^^^^^

  Unknown operator (+)

Add value source positions purescript#1801

Add value source positions (#2427)

[1/8 CannotFindDerivingType]

  Cannot derive a type class instance, because the type declaration for VarMapValue could not be found.

I've started working on an AST representation in which source span annotations will be necessary everywhere, which should help a lot here. It's going to take a while though, since it's a big change.

Not sure if this goes here or not, but thought I'd post. I can open a new ticket if so.

If you leave out a comma when defining a type alias, the compiler things there is a kind error.

http://try.purescript.org/?gist=565439f559aa752c3110d64b49409ae3&backend=core&session=7c6d335a-259a-188f-64b3-c51db1831f8c

type Asset = {
  name :: String
  list :: Array String
}

Unknown kind Array

Note from #3276, we could improve MissingFFIImplementations to point at specific members rather than listing them by name and just having a whole module span.

TypesDoNotUnify

When a type mismatch arises as a result of a use of the record update syntax r { x = y } where r is not a record, the span seems to be larger than necessary:

makeRecord x = { x, y: 0 }

eg =
  case unit of
    _ ->
      makeRecord 0 { y = 1 }

Note that for this to typecheck you would need to write (makeRecord 0) { y = 1 }. The source span for this error is currently the entire eg declaration.

TypesDoNotUnify

When a record field does not match, the error span sometimes covers the entire record literal. I've found that this problem is more likely to arise in the presence of type applications, i.e. having Array String versus Maybe String seems more likely to result in a bad error span than say String versus Int.

module Main where

import Prelude
import Data.Maybe

eg :: { foo :: String, bar :: Array Int }
eg =
  { foo: "hi"
  , bar: Just "hi"
  }

I've checked all the outstanding test cases, and the list is now up to date as of the v0.14 release candidates. Remaining items behave as follows:

TransitiveExportError: spans the entire module
MissingFFIImplementations: spans the entire module
KindsDoNotUnify: highlights a relevant token, but not the most intuitive/helpful ones
TypesDoNotUnify: highlights the wrong part of the do block

I gave CycleInModules credit because it now highlights the module header and imports block. Conceivably it could zero in on the problematic import(s) but I don't think that's always possible in the case of complex cycles, in which case I'm not sure what the ideal behavior would be.

Is the affects-v0.14.0 label new? What does it mean exactly?

It means I've confirmed the bug is still present in 0.14. Right now it's functioning as a checklist as I go through our list of 60 open bugs and look for anything that can be trivially closed; going forward, my thought was that it'll get replaced by affects-v0.15.0 etc. on bugs that continue to be confirmed on newer versions of PS, and thus serve as a staleness indicator for the next person doing housekeeping. (If you think this is a bad idea, I can stop using the label.)

Ah, I see, thanks. Not at all, that sounds great - thank you for doing this!

Navigation Menu

Repository navigation

Incorrect error/warning position ranges #1801

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect error/warning position ranges #1801

Description

Activity

natefaubion commented on Jan 7, 2016

natefaubion commented on Jan 7, 2016

natefaubion commented on Jan 7, 2016

natefaubion commented on Jan 7, 2016

user471 commented on Jan 12, 2016

natefaubion commented on Jan 12, 2016

user471 commented on Jan 13, 2016

user471 commented on Jan 16, 2016

user471 commented on Jan 16, 2016

user471 commented on Jan 26, 2016

natefaubion commented on Jan 31, 2016

user471 commented on Feb 4, 2016

22 remaining items

nwolverson commented on Nov 10, 2016

natefaubion commented on Jan 6, 2017

paf31 commented on Jan 11, 2017

dgendill commented on May 7, 2017

garyb commented on Mar 12, 2018

hdgarrood commented on Dec 8, 2018

hdgarrood commented on Feb 27, 2019

rhendric commented on Dec 26, 2020

hdgarrood commented on Dec 26, 2020

rhendric commented on Dec 26, 2020

hdgarrood commented on Dec 26, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions