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

Quick fix type mismatch #188

Merged
merged 9 commits into from Oct 3, 2012

Conversation

Projects
None yet
6 participants
@ikuraj
Contributor

ikuraj commented Aug 21, 2012

Hi all,

I should have posted this pull request while ago, but now I refactored it a bit so I guess it is ready for pull request.

This is a small pull request, and it provides an implementation of quick fixes when a type missmatch error occurs - e.g. "type mismatch: found Type; required Option[Type]" -> quick fixes suggest to wrap the result in Some().
The implementation is designed to be extensible in a sense that developers can add their own cases of type mismatch and transformations.

For example if one wants to add a quick fix in case of "type mismatch: List[T] but found List[List[T]]" to suggest .flatten, .head or .last call, one could use the add an FoundToRequiredTypeCase object to the cases list which represents all cases of type missmatch errors that should be covered.
Explanation on how to construct such objects is given in the source documentation. The object that does the mentioned quick fix is here.

Some notes on the pull request:

  • Apparently sometimes, the quick fix processor is called multiple times, thus resulting in multiple (identical) quick fixes being offered.
    Test case:
    def f2(l: Option[Int]) = 4    
    val intVal = 5
    f2(intVal) // <- quick fix here

When two identical (valid) quick fixes are offered. That is an issue of the quick fixe facility itself - should we submit a ticket maybe?

  • Encountered a potential code duplication in the quick fix code. Note that XXX is added at the end of the method name...

Cheers,
Ivan

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 21, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 21, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 21, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 21, 2012

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Aug 22, 2012

Member

A general comment: is it possible to add a test for this functionality?

Member

dragos commented Aug 22, 2012

A general comment: is it possible to add a test for this functionality?

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Aug 23, 2012

Contributor

Yes, I forgot to mention this. There are no tests that test quick fixes for the Scala IDE currently, if I am not mistaking.

Maybe it would be good to get some feedback from the people who wrote other quick fixes (e.g. class ScalaQuickFixProcessor)?

Of course we could always observe what it is already done for the Eclipse JDT (e.g. AssistQuickFixTest)...

Contributor

ikuraj commented Aug 23, 2012

Yes, I forgot to mention this. There are no tests that test quick fixes for the Scala IDE currently, if I am not mistaking.

Maybe it would be good to get some feedback from the people who wrote other quick fixes (e.g. class ScalaQuickFixProcessor)?

Of course we could always observe what it is already done for the Eclipse JDT (e.g. AssistQuickFixTest)...

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Aug 23, 2012

Contributor

By the way, the pr-validator-master-trunk build fails with or without my additions, if I am not mistaking.

Contributor

ikuraj commented Aug 23, 2012

By the way, the pr-validator-master-trunk build fails with or without my additions, if I am not mistaking.

@dotta

This comment has been minimized.

Show comment
Hide comment
@dotta

dotta Aug 23, 2012

Member

I've fixed 2.10 build, so let's give it another spin.

Member

dotta commented Aug 23, 2012

I've fixed 2.10 build, so let's give it another spin.

@dotta

This comment has been minimized.

Show comment
Hide comment
@dotta

dotta Aug 23, 2012

Member

PLS REBUILD ALL

Member

dotta commented Aug 23, 2012

PLS REBUILD ALL

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 23, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 23, 2012

@dotta

This comment has been minimized.

Show comment
Hide comment
@dotta

dotta Aug 23, 2012

Member

e.g. "type mismatch: found Type; required Option[Type]" -> quick fixes suggest to wrap the result in Some()

Any reason for wrapping with Some? I would have expected Option so that null is mapped to None.

Member

dotta commented Aug 23, 2012

e.g. "type mismatch: found Type; required Option[Type]" -> quick fixes suggest to wrap the result in Some()

Any reason for wrapping with Some? I would have expected Option so that null is mapped to None.

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 23, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Aug 23, 2012

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Aug 23, 2012

Contributor

Oh, I got the notification about your changes just now... :/ Excellent, the 2.10 build is fine now.

If I understood your remark correctly you suggest that null wraps to None if Option[T] is expected. Isn't it the case that at the place where Option[T] is expected passing null is valid (and does not generate a compiler error marker, i.e. no quick fix functionality is invoked)?

Contributor

ikuraj commented Aug 23, 2012

Oh, I got the notification about your changes just now... :/ Excellent, the 2.10 build is fine now.

If I understood your remark correctly you suggest that null wraps to None if Option[T] is expected. Isn't it the case that at the place where Option[T] is expected passing null is valid (and does not generate a compiler error marker, i.e. no quick fix functionality is invoked)?

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Sep 1, 2012

Member

If you pass the null literal, yes, but I don't think that case comes up very often in practice. An expression that has type T may still be null at runtime. In order to correctly make it an Option[T] you need to call Option(e), not Some(e). Some(null) should be avoided at all costs. Option.apply checks the argument for null and returns Some or None accordingly.

Member

dragos commented Sep 1, 2012

If you pass the null literal, yes, but I don't think that case comes up very often in practice. An expression that has type T may still be null at runtime. In order to correctly make it an Option[T] you need to call Option(e), not Some(e). Some(null) should be avoided at all costs. Option.apply checks the argument for null and returns Some or None accordingly.

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Sep 3, 2012

Contributor

Yes, I agree, I just wanted to point out that quick fix type mismatch errors are of the form "type mismatch: found A; required B" and the Eclipse quick fix functionality is invoked according to the marker that encapsules such compiler error messages. That should mean that if we encounter a marker with message saying that type T is found while Option[T] is required, wrapping the expression in Some(_) seems appropriate.

Using null value in a similar scenario cannot generate such marker (with such message) and therefore cannot invoke this specific functionality of quick fix type mismatch, therefore offering Some(null) will be avoided (passing null in a place where Option[T] is expected should not invoke the functionality implemented in this pull request).

Contributor

ikuraj commented Sep 3, 2012

Yes, I agree, I just wanted to point out that quick fix type mismatch errors are of the form "type mismatch: found A; required B" and the Eclipse quick fix functionality is invoked according to the marker that encapsules such compiler error messages. That should mean that if we encounter a marker with message saying that type T is found while Option[T] is required, wrapping the expression in Some(_) seems appropriate.

Using null value in a similar scenario cannot generate such marker (with such message) and therefore cannot invoke this specific functionality of quick fix type mismatch, therefore offering Some(null) will be avoided (passing null in a place where Option[T] is expected should not invoke the functionality implemented in this pull request).

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Sep 3, 2012

Member

Sure, we agree on null not generating an error message, therefore there's no way you'd generate Some(null). But I wanted to say something else:

Given an expression e: T, you should not replace it by Some(e), unless you can prove that at runtime e can never be null. Since such an analysis is not performed, you need a runtime test to decide if e is null or not. That is precisely what Option.apply does: it checks the argument for null, and returns Some(e) or None accordingly.

Member

dragos commented Sep 3, 2012

Sure, we agree on null not generating an error message, therefore there's no way you'd generate Some(null). But I wanted to say something else:

Given an expression e: T, you should not replace it by Some(e), unless you can prove that at runtime e can never be null. Since such an analysis is not performed, you need a runtime test to decide if e is null or not. That is precisely what Option.apply does: it checks the argument for null, and returns Some(e) or None accordingly.

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Sep 3, 2012

Contributor

Yes, I see now, maybe quick fixes should wrap the expression in Option(_) rather than in Some(_), but in that case the runtime check is payed also in majority of cases where it is not needed. Maybe suggesting both is the best solution?
I guess, given the Scala type system, we cannot be sure whether the value is null or not...

Contributor

ikuraj commented Sep 3, 2012

Yes, I see now, maybe quick fixes should wrap the expression in Option(_) rather than in Some(_), but in that case the runtime check is payed also in majority of cases where it is not needed. Maybe suggesting both is the best solution?
I guess, given the Scala type system, we cannot be sure whether the value is null or not...

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Sep 3, 2012

Member

It's ok to suggest Option in all cases. Until non-nullable types appear in Scala, we can't do better.

Member

dragos commented Sep 3, 2012

It's ok to suggest Option in all cases. Until non-nullable types appear in Scala, we can't do better.

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Sep 3, 2012

For those of us that avoid null, using Some seems more appropriate. I like the idea of offering both options. Using Option.apply when no nulls are expected makes things less clear if a null sneaks in.

ijuma commented Sep 3, 2012

For those of us that avoid null, using Some seems more appropriate. I like the idea of offering both options. Using Option.apply when no nulls are expected makes things less clear if a null sneaks in.

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Sep 4, 2012

Member

I'm more fond of the idea that we should be safe. QuickFix is a simple solution to a common problem, and it's probably going to be used by novices. I don't want it to introduce subtle bugs.

The problem with Some is that it does not assert(x nu null), so it silently propagates Some(null) until it blows up later. As someone who's been bitten by Some(null), I definitely avoid Some(expr) like the plague.

One possibility for offering Some as an alternative is to add an assert(e ne null) together with it. Then, experts can delete it consciously.

Member

dragos commented Sep 4, 2012

I'm more fond of the idea that we should be safe. QuickFix is a simple solution to a common problem, and it's probably going to be used by novices. I don't want it to introduce subtle bugs.

The problem with Some is that it does not assert(x nu null), so it silently propagates Some(null) until it blows up later. As someone who's been bitten by Some(null), I definitely avoid Some(expr) like the plague.

One possibility for offering Some as an alternative is to add an assert(e ne null) together with it. Then, experts can delete it consciously.

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Sep 4, 2012

I understand your concerns. Two points though: quick fixes in JDT are not how you describe them. Since explicit action is required, it doesn't have to be 100% safe (impossible to guarantee anyway). If Option.apply is the first quick fix, people would have to make an effort to choose the second one. The second point is that converting an unexpected null to None does not make errors more obvious.

I agree that it's unfortunate that we don't have a method that fails on nulls before providing a Some.

ijuma commented Sep 4, 2012

I understand your concerns. Two points though: quick fixes in JDT are not how you describe them. Since explicit action is required, it doesn't have to be 100% safe (impossible to guarantee anyway). If Option.apply is the first quick fix, people would have to make an effort to choose the second one. The second point is that converting an unexpected null to None does not make errors more obvious.

I agree that it's unfortunate that we don't have a method that fails on nulls before providing a Some.

@dotta

This comment has been minimized.

Show comment
Hide comment
@dotta

dotta Sep 21, 2012

Member

Guys, where do we stand with this PR?

Member

dotta commented Sep 21, 2012

Guys, where do we stand with this PR?

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Sep 21, 2012

Contributor

I guess we should decide with which alternative should we go with. Perhaps suggesting both is the best compromise?

Contributor

ikuraj commented Sep 21, 2012

I guess we should decide with which alternative should we go with. Perhaps suggesting both is the best compromise?

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Sep 21, 2012

I still think we should offer both with Option(..) first. If that's seen as unacceptable, then just the one is better than nothing, I guess. I know I won't ever use it, but others will.

ijuma commented Sep 21, 2012

I still think we should offer both with Option(..) first. If that's seen as unacceptable, then just the one is better than nothing, I guess. I know I won't ever use it, but others will.

@dotta

This comment has been minimized.

Show comment
Hide comment
@dotta

dotta Sep 21, 2012

Member

Personally, I'd go with just Option.

Member

dotta commented Sep 21, 2012

Personally, I'd go with just Option.

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Sep 29, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Sep 29, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Sep 29, 2012

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Sep 30, 2012

Contributor

In the last commit, I included a test for quick fixes which I was working on following implementations for the QuickFix JDT tests (e.g. here and here). Unfortunately, it does not pass because calls to JavaCorrectionProcessor (here) does not return any corrections (nor assists).

Any ideas ?

Contributor

ikuraj commented Sep 30, 2012

In the last commit, I included a test for quick fixes which I was working on following implementations for the QuickFix JDT tests (e.g. here and here). Unfortunately, it does not pass because calls to JavaCorrectionProcessor (here) does not return any corrections (nor assists).

Any ideas ?

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Sep 30, 2012

Member

Does it pass when you run it locally, or it never passes?

Member

dragos commented Sep 30, 2012

Does it pass when you run it locally, or it never passes?

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Sep 30, 2012

Contributor

It never passes.
Note that problems are correctly returned from the compiler as expected (here) - they all have expected messages, same as if one highlights the error markers in the Eclipse editor - so I guess that there is a problem with the JavaCorrectionProcessor (perhaps due to the weaving?).

Contributor

ikuraj commented Sep 30, 2012

It never passes.
Note that problems are correctly returned from the compiler as expected (here) - they all have expected messages, same as if one highlights the error markers in the Eclipse editor - so I guess that there is a problem with the JavaCorrectionProcessor (perhaps due to the weaving?).

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Oct 1, 2012

Member

Unfortunately, I don't know what JavaCorrectionProcessor is supposed to do, or how it collects assists. Can't you test it more directly than that, maybe by adding a method in ScalaCompilationUnit to return quick fixes/assists?

Member

dragos commented Oct 1, 2012

Unfortunately, I don't know what JavaCorrectionProcessor is supposed to do, or how it collects assists. Can't you test it more directly than that, maybe by adding a method in ScalaCompilationUnit to return quick fixes/assists?

@misto

This comment has been minimized.

Show comment
Hide comment
@misto

misto Oct 2, 2012

Member

I think I have an idea why the tests don't work. ScalaQuickFixProcessor opens a new editor, and then tries to get the annotations, which doesn't find any. But when I sleep for a few seconds after opening the editor, the annotations are found.. so I guess you somehow need to wait until the editor is fully initialized and all the annotations are available.

Member

misto commented Oct 2, 2012

I think I have an idea why the tests don't work. ScalaQuickFixProcessor opens a new editor, and then tries to get the annotations, which doesn't find any. But when I sleep for a few seconds after opening the editor, the annotations are found.. so I guess you somehow need to wait until the editor is fully initialized and all the annotations are available.

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Oct 2, 2012

Contributor

I thought that JavaCorrectionProcessor is a class for returning corrections (and assists) globally that can be used also for the Scala editor (I was trying to write these test in the correct way by mimicking tests found in JDT testing code).

I've tried using ScalaQuickFixProcessor as you mentioned, but I received null as a result of getCorrections call (when given a problem argument that seems to be valid).

Contributor

ikuraj commented Oct 2, 2012

I thought that JavaCorrectionProcessor is a class for returning corrections (and assists) globally that can be used also for the Scala editor (I was trying to write these test in the correct way by mimicking tests found in JDT testing code).

I've tried using ScalaQuickFixProcessor as you mentioned, but I received null as a result of getCorrections call (when given a problem argument that seems to be valid).

@misto

This comment has been minimized.

Show comment
Hide comment
@misto

misto Oct 2, 2012

Member

In org.eclipse.jdt.inernal.ui.text.correction.JavaCorrectionProcessor, you can see that collectCorrections uses quickFixProcessors contributions and collectAssists uses quickAssistsProcessors. You're right that this alone doesn't solve it, but with collectCorrections and a sleep in ScalaQuickFixProcessor I get the corrections in the tests.

Member

misto commented Oct 2, 2012

In org.eclipse.jdt.inernal.ui.text.correction.JavaCorrectionProcessor, you can see that collectCorrections uses quickFixProcessors contributions and collectAssists uses quickAssistsProcessors. You're right that this alone doesn't solve it, but with collectCorrections and a sleep in ScalaQuickFixProcessor I get the corrections in the tests.

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Oct 2, 2012

Contributor

Thanks for the explanation! Actually I was trying collectCorrections first but gave a try also to collectAssists just to see what if maybe the results were different (they were not :)).

Contributor

ikuraj commented Oct 2, 2012

Thanks for the explanation! Actually I was trying collectCorrections first but gave a try also to collectAssists just to see what if maybe the results were different (they were not :)).

@misto

This comment has been minimized.

Show comment
Hide comment
@misto

misto Oct 2, 2012

Member

Try this:

--- a/org.scala-ide.sdt.core/src/scala/tools/eclipse/quickfix/ScalaQuickFixProcessor.scala
+++ b/org.scala-ide.sdt.core/src/scala/tools/eclipse/quickfix/ScalaQuickFixProcessor.scala
@@ -62,6 +62,7 @@ class ScalaQuickFixProcessor extends IQuickFixProcessor with HasLogger {
     context.getCompilationUnit match {
       case ssf : ScalaSourceFile => {
        val editor = JavaUI.openInEditor(context.getCompilationUnit)
+       Thread.sleep(5000)
         var corrections : List[IJavaCompletionProposal] = Nil
         for (location <- locations)

then you should get corrections :-)

Member

misto commented Oct 2, 2012

Try this:

--- a/org.scala-ide.sdt.core/src/scala/tools/eclipse/quickfix/ScalaQuickFixProcessor.scala
+++ b/org.scala-ide.sdt.core/src/scala/tools/eclipse/quickfix/ScalaQuickFixProcessor.scala
@@ -62,6 +62,7 @@ class ScalaQuickFixProcessor extends IQuickFixProcessor with HasLogger {
     context.getCompilationUnit match {
       case ssf : ScalaSourceFile => {
        val editor = JavaUI.openInEditor(context.getCompilationUnit)
+       Thread.sleep(5000)
         var corrections : List[IJavaCompletionProposal] = Nil
         for (location <- locations)

then you should get corrections :-)

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Oct 2, 2012

Contributor

Yes, that seems to be working, thanks again - but is a terrible hack :)))
There are some solutions that can be found online, but I would not burden the "common case" of the QuickFixProcessor... Would you agree?

That's why I've opened an editor and added waiting time into the tests themselves, and the subsequent calls to JavaUI.openInEditor just returned the already opened instance. ScalaQuickFixProcessor can remain unchanged.

I will commit (hopefully working) tests ASAP

Contributor

ikuraj commented Oct 2, 2012

Yes, that seems to be working, thanks again - but is a terrible hack :)))
There are some solutions that can be found online, but I would not burden the "common case" of the QuickFixProcessor... Would you agree?

That's why I've opened an editor and added waiting time into the tests themselves, and the subsequent calls to JavaUI.openInEditor just returned the already opened instance. ScalaQuickFixProcessor can remain unchanged.

I will commit (hopefully working) tests ASAP

@misto

This comment has been minimized.

Show comment
Hide comment
@misto

misto Oct 2, 2012

Member

Oh yes, terrible hack.. it wasn't meant as a solution for the problem, just to point out the issue :-)

Member

misto commented Oct 2, 2012

Oh yes, terrible hack.. it wasn't meant as a solution for the problem, just to point out the issue :-)

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Oct 2, 2012

Contributor

And it did point out the issue! The tests are working, without changing anything in the core module ;)

P.S. And I guess using the JavaCorrectionProcessor (which uses all those contributions as you mentioned) rather than ScalaQuickFixProcessor directly is the right way to test it - after all, computing proposals directly from the ScalaQuickFixProcessor cannot guarantee us that it will be invoked when the IDE is actually ran.

Contributor

ikuraj commented Oct 2, 2012

And it did point out the issue! The tests are working, without changing anything in the core module ;)

P.S. And I guess using the JavaCorrectionProcessor (which uses all those contributions as you mentioned) rather than ScalaQuickFixProcessor directly is the right way to test it - after all, computing proposals directly from the ScalaQuickFixProcessor cannot guarantee us that it will be invoked when the IDE is actually ran.

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Oct 2, 2012

Contributor

Note that support for wrapping literals into Option is commented at the moment because besides the valid annotation, compiler returns some strange things as annotations (e.g. for 'c' it should return only 'c', but it also returns ').
This quickfix (and tests) are commented.

Other things are working (with respect to small issues mentioned in the description).

Contributor

ikuraj commented Oct 2, 2012

Note that support for wrapping literals into Option is commented at the moment because besides the valid annotation, compiler returns some strange things as annotations (e.g. for 'c' it should return only 'c', but it also returns ').
This quickfix (and tests) are commented.

Other things are working (with respect to small issues mentioned in the description).

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Oct 2, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Oct 2, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Oct 2, 2012

@scala-jenkins

This comment has been minimized.

Show comment
Hide comment
@scala-jenkins

scala-jenkins commented Oct 2, 2012

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Oct 3, 2012

Member

LGTM.

Member

dragos commented Oct 3, 2012

LGTM.

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Oct 3, 2012

Member

BTW, this is not exactly the place to have this discussion, but would it be easy to add a quick fix for misspelled names? For instance, I often mistake the case, or swap a letter in a method name. It would be cool if it showed me what I meant to write. :)

Member

dragos commented Oct 3, 2012

BTW, this is not exactly the place to have this discussion, but would it be easy to add a quick fix for misspelled names? For instance, I often mistake the case, or swap a letter in a method name. It would be cool if it showed me what I meant to write. :)

@ikuraj

This comment has been minimized.

Show comment
Hide comment
@ikuraj

ikuraj Oct 3, 2012

Contributor

Excellent, so this pull request is ready then (but again, note the things mentioned in the description).

Yes, I would say that this should be a similar quick fix which handles errors with messages _"value not found: ". Should that be a separate pull request?

Contributor

ikuraj commented Oct 3, 2012

Excellent, so this pull request is ready then (but again, note the things mentioned in the description).

Yes, I would say that this should be a similar quick fix which handles errors with messages _"value not found: ". Should that be a separate pull request?

@dragos

This comment has been minimized.

Show comment
Hide comment
@dragos

dragos Oct 3, 2012

Member

Cool, if you feel like contributing that, it should be a separate pull request!

Member

dragos commented Oct 3, 2012

Cool, if you feel like contributing that, it should be a separate pull request!

dragos added a commit that referenced this pull request Oct 3, 2012

@dragos dragos merged commit c30ce05 into scala-ide:master Oct 3, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment