Skip to content

Local error in block causes spurious errors in outer tree to be reported #2412

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.

Sign up for GitHub

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

Jump to bottom
Closed
smarter opened this issue May 11, 2017 · 0 comments
Closed

Local error in block causes spurious errors in outer tree to be reported #2412

smarter opened this issue May 11, 2017 · 0 comments
Assignees
@smarter
Labels
area:typer itype:bug prio:low stat:fix available

Comments

@smarter
Copy link
Member

smarter commented May 11, 2017 •
edited
Loading

This code should only report one error:

object Test {
  def test(foo: List[String]): Unit = {
    foo.filter(f => {
      iDontExist // error
      true
    })
  }
}

But with dotty we get two:

-- Error: try/err.scala:3:15 ---------------------------------------------------
3 |    foo.filter(f => {
  |               ^
  |               missing parameter type for parameter f, expected = ?
-- [E006] Unbound Identifier Error: try/err.scala:4:6 --------------------------
4 |      iDontExist
  |      ^^^^^^^^^^
  |      not found: iDontExist

Even though the type of f is correctly inferred as String, as can be seen using -Xprint:frontend. Interestingly this does not happen if we replace filter by map. This seems to be related to the way we fallback in typedApply: https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/dotc/typer/Applications.scala#L695-L707
@smarter smarter mentioned this issue Jun 10, 2017
Closed
smarter added a commit to smarter/dotty that referenced this issue Jul 25, 2017
@smarter
Fix scala#2412: Local error causes spurious errors to be reported
c6dec50 
`FunProto#typedArgs` was using the implicit Context from the `FunProto`
constructor, and thus errors weren't stored in the proper context.
smarter added a commit to smarter/dotty that referenced this issue Jul 26, 2017
@smarter
Fix scala#2412: Local error causes spurious errors to be reported
72d5835 
`FunProto#typedArgs` was using the implicit Context from the `FunProto`
constructor, and thus errors weren't stored in the proper context.
This is fixed by passing an implicit Context argument to
`typedArgs` (this was already done for `typedArg`), this means that we
no longer need to store a Context in the class, on the other hand there
are some new difficulties:
- `FunProto#typedArgs` can only be safely called from a point where the
  implicit Context contains the Context where the `FunProto` instance was
  created in its owner chain. This is usually the case but required some
  changes to Implicits (done in the previous commit)
- The Context used must be created with Context#thisCallArgContext when
  typing the arguments of a this(...) constructor call. This requires
  passing storing this information in FunProto. This wouldn't be necessary
  if we could simply type the whole this(...) Apply node with
  Context#thisCallArgContext, unfortunately this does not work since this
  Context does not have the constructors of the class in scope, and I did
  not figure out a way to construct a Context that would have them in
  scope without having the other methods of the class in scope.
smarter added a commit to smarter/dotty that referenced this issue Jul 26, 2017
@smarter
Fix scala#2412: Local error causes spurious errors to be reported
9b3d26e 
`FunProto#typedArgs` was using the implicit Context from the `FunProto`
constructor, and thus errors weren't stored in the proper context.
This is fixed by passing an implicit Context argument to
`typedArgs` (this was already done for `typedArg`), this means that we
no longer need to store a Context in the class, on the other hand there
are some new difficulties:
- `FunProto#typedArgs` can only be safely called from a point where the
  implicit Context contains the Context where the `FunProto` instance was
  created in its owner chain. This is usually the case but required some
  changes to Implicits (done in the previous commit)
- The Context used must be created with Context#thisCallArgContext when
  typing the arguments of a this(...) constructor call. This requires
  passing storing this information in FunProto. This wouldn't be necessary
  if we could simply type the whole this(...) Apply node with
  Context#thisCallArgContext, unfortunately this does not work since this
  Context does not have the constructors of the class in scope, and I did
  not figure out a way to construct a Context that would have them in
  scope without having the other methods of the class in scope.
smarter added a commit to dotty-staging/dotty that referenced this issue Jul 26, 2017
@smarter
Fix scala#2412: Local error causes spurious errors to be reported
1fef282 
`FunProto#typedArgs` was using the implicit Context from the `FunProto`
constructor, and thus errors weren't stored in the proper context.
This is fixed by passing an implicit Context argument to
`typedArgs` (this was already done for `typedArg`), this means that we
no longer need to store a Context in the class, on the other hand there
are some new difficulties:
- `FunProto#typedArgs` can only be safely called from a point where the
  implicit Context contains the Context where the `FunProto` instance was
  created in its owner chain. This is usually the case but required some
  changes to Implicits (done in the previous commit)
- The Context used must be created with Context#thisCallArgContext when
  typing the arguments of a this(...) constructor call. This requires
  passing storing this information in FunProto. This wouldn't be necessary
  if we could simply type the whole this(...) Apply node with
  Context#thisCallArgContext, unfortunately this does not work since this
  Context does not have the constructors of the class in scope, and I did
  not figure out a way to construct a Context that would have them in
  scope without having the other methods of the class in scope.
smarter added a commit to dotty-staging/dotty that referenced this issue Jul 27, 2017
@smarter
Fix scala#2412: Local error causes spurious errors to be reported
66801cc 
`FunProto#typedArgs` was using the implicit Context from the `FunProto`
constructor, and thus errors weren't stored in the proper context.
This is fixed by passing an implicit Context argument to
`typedArgs` (this was already done for `typedArg`), this means that we
no longer need to store a Context in the class, on the other hand there
are some new difficulties:
- `FunProto#typedArgs` can only be safely called from a point where the
  implicit Context contains the Context where the `FunProto` instance was
  created in its owner chain. This is usually the case but required some
  changes to Implicits (done in the previous commit)
- The Context used must be created with Context#thisCallArgContext when
  typing the arguments of a this(...) constructor call. This requires
  passing storing this information in FunProto. This wouldn't be necessary
  if we could simply type the whole this(...) Apply node with
  Context#thisCallArgContext, unfortunately this does not work since this
  Context does not have the constructors of the class in scope, and I did
  not figure out a way to construct a Context that would have them in
  scope without having the other methods of the class in scope.
smarter added a commit to dotty-staging/dotty that referenced this issue Oct 6, 2017
@smarter
Fix scala#2412: Local error causes spurious errors to be reported
04c0f66 
`FunProto#typedArgs` was using the implicit Context from the `FunProto`
constructor, and thus errors weren't stored in the proper context.
This is fixed by passing an implicit Context argument to
`typedArgs` (this was already done for `typedArg`), this means that we
no longer need to store a Context in the class, on the other hand there
are some new difficulties:
- `FunProto#typedArgs` can only be safely called from a point where the
  implicit Context contains the Context where the `FunProto` instance was
  created in its owner chain. This is usually the case but required some
  changes to Implicits (done in the previous commit)
- The Context used must be created with Context#thisCallArgContext when
  typing the arguments of a this(...) constructor call. This requires
  passing storing this information in FunProto. This wouldn't be necessary
  if we could simply type the whole this(...) Apply node with
  Context#thisCallArgContext, unfortunately this does not work since this
  Context does not have the constructors of the class in scope, and I did
  not figure out a way to construct a Context that would have them in
  scope without having the other methods of the class in scope.
@smarter smarter mentioned this issue Jan 11, 2018
Merged
@smarter smarter closed this as completed in baee69f Aug 9, 2018
smarter added a commit that referenced this issue Aug 9, 2018
@smarter
Merge pull request #4912 from dotty-staging/fix-#2412
1ded4f9 
Fix #2412: Add regression test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@smarter smarter

Labels
area:typer itype:bug prio:low stat:fix available
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@smarter @nicolasstucki