#683
- Created on2008-03-26 16:34
- Reported by
- StatusAccepted
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
If any files with errors, does not compile even those that are fine
Migrated from http://lampsvn.epfl.ch/trac/scala/ticket/683
Reporter gnp
If I have a file with an object with a main method that has no errors, and I also have another file that has one or more errors in it, then when I try to run the one without errors it doesn't run because the compiler does not generate source files.
I have tried with Build Automatically both on and off.
I am running on Mac OS X Leopard. Eclipse 3.3. Latest plugin as of 2008-03-26 (2.7.0-14271-final_0).
When I was having trouble with this originally, I created a new Scala project in Eclipse, and copied over the package containing the source for the object without errors. It ran fine. Then I copied over the package containing the source for the object that had errors, and it did not run (class not found). When I've gotten the class not found error, and I've looked in the bin directory, there are no .class files in there.
Seems like the compiler is aborting without producing any output when one or more classes have errors. This is not expected behavior. Things that can compile cleanly should. You should be able to incrementally fix things and get more and more of the stuff working. As it is you have to fix everything before anything will run.
In my case, the package containing the error sorted lexicographically before the one that had no error that I was trying to run. I thought maybe if I arranged for it to come after the package that is good, I'd get the output files for the good stuff, but that didn't work either.
Reporter gnp
If I have a file with an object with a main method that has no errors, and I also have another file that has one or more errors in it, then when I try to run the one without errors it doesn't run because the compiler does not generate source files.
I have tried with Build Automatically both on and off.
I am running on Mac OS X Leopard. Eclipse 3.3. Latest plugin as of 2008-03-26 (2.7.0-14271-final_0).
When I was having trouble with this originally, I created a new Scala project in Eclipse, and copied over the package containing the source for the object without errors. It ran fine. Then I copied over the package containing the source for the object that had errors, and it did not run (class not found). When I've gotten the class not found error, and I've looked in the bin directory, there are no .class files in there.
Seems like the compiler is aborting without producing any output when one or more classes have errors. This is not expected behavior. Things that can compile cleanly should. You should be able to incrementally fix things and get more and more of the stuff working. As it is you have to fix everything before anything will run.
In my case, the package containing the error sorted lexicographically before the one that had no error that I was trying to run. I thought maybe if I arranged for it to come after the package that is good, I'd get the output files for the good stuff, but that didn't work either.
Leave a comment
on 2008-04-20 16:58 *
By tracImporter
Trac author: mcdirmid
This is a long standing complaint that I have with the design of NSC, but Martin has to decide that this is a problem that needs to be fixed.If there is an error in one file, follow through with files that don't have errors, rather than just aborting the entire compilation.
This is a long standing complaint that I have with the design of NSC, but Martin has to decide that this is a problem that needs to be fixed.If there is an error in one file, follow through with files that don't have errors, rather than just aborting the entire compilation.
on 2008-04-21 05:07 *
By tracImporter
Trac author: gnp
This is a major impediment to working with the Eclipse plugin, which uses this compiler. A person might find himself in the position of having a core library that would compile without error, yet have two or more test cases that have errors because they need to be adapted to conform to some changes made in the core. Imagine doing a substantial refactoring of a framework. It is very important that people be able to fix and test things incrementally. Not only is this a problem for normal work-a-day activities, but it is extremely frustrating to people (like me) learning Scala.
I hope you will agree that especially in the (common nowadays) situation where people are using an IDE, the expectation is that you can work with your code incrementally and have the IDE (and compiler) help you work in an incremental fashion.
The Java tooling for Eclipse does prompt you to see if you really want to run if you request a run while there are errors.
I think the situation I was in was amplified by some other bugs in the plugin where it was very temperamental about doing syntax highlighting, and I was not sure what the errors I had made were. I wanted to test out certain things off to the side to aid learning and then come back to the central issue.
This is a major impediment to working with the Eclipse plugin, which uses this compiler. A person might find himself in the position of having a core library that would compile without error, yet have two or more test cases that have errors because they need to be adapted to conform to some changes made in the core. Imagine doing a substantial refactoring of a framework. It is very important that people be able to fix and test things incrementally. Not only is this a problem for normal work-a-day activities, but it is extremely frustrating to people (like me) learning Scala.
I hope you will agree that especially in the (common nowadays) situation where people are using an IDE, the expectation is that you can work with your code incrementally and have the IDE (and compiler) help you work in an incremental fashion.
The Java tooling for Eclipse does prompt you to see if you really want to run if you request a run while there are errors.
I think the situation I was in was amplified by some other bugs in the plugin where it was very temperamental about doing syntax highlighting, and I was not sure what the errors I had made were. I wanted to test out certain things off to the side to aid learning and then come back to the central issue.
on 2008-05-21 18:02 *
By tracImporter
Trac author: odersky
It's not so easy. The problem is that all transformation phases (and there are many of those!) assume that all code is correct. It's not possible to change that assumption and have the compiler still work reliably; we'd see random crashes in backends for months if not years. An error in one file can easily cause errors in other files. The only solution I see is to do dependency tracking in Eclipse, and still compile those files that do now depend on any erroneous file.
I let Miles have a look whether this is feasable.
It's not so easy. The problem is that all transformation phases (and there are many of those!) assume that all code is correct. It's not possible to change that assumption and have the compiler still work reliably; we'd see random crashes in backends for months if not years. An error in one file can easily cause errors in other files. The only solution I see is to do dependency tracking in Eclipse, and still compile those files that do now depend on any erroneous file.
I let Miles have a look whether this is feasable.
on 2008-05-21 18:03 *
By tracImporter
Trac author: odersky
I meant tpo write:
The only solution I see is to do dependency tracking in Eclipse, and still compile those files that do not depend on any erroneous file.
I meant tpo write:
The only solution I see is to do dependency tracking in Eclipse, and still compile those files that do not depend on any erroneous file.
on 2009-09-02 01:45 *
By tracImporter
Trac author: ColinHowe
I can confirm that this is still an issue in 2.8.0.r18604 To replicate:
I can confirm that this is still an issue in 2.8.0.r18604 To replicate:
- Create two objects, Test1 and Test2 (both with main methods)
- Create a syntax error in Test2
- Do a clean of the project
- Attempt to run Test1
on 2009-11-29 13:02 *
By tracImporter
Trac author: spiros
CC Change: sptz45@…
CC Change: sptz45@…
on 2010-01-20 09:09 *
By tracImporter
Trac author: ijuma
CC Change: mlists@…
CC Change: mlists@…
on 2010-10-24 20:07 *
By
Just speculating here, I'm guessing JDT gets around this by always caching the symbols each file contained the last time it compiled successfully and using that cache when building files that depend on it. That way, when you break a source file and symbols that are used in other places are no longer present according to the compiler, the files that depend on the broken file don't consider the changes until the broken file is repaired.
It seems like taking this sort of approach would require much tighter integration with the compiler, which JDT gets because they have their own compiler.
It seems like taking this sort of approach would require much tighter integration with the compiler, which JDT gets because they have their own compiler.
Updating tickets (#1000069, #1000195, #1000213, #1000223, #1000006, #1000021, #1000038, #1000048, #1000051, #1000052, #1000075, #1000103, #1000109, #1000115, #1000119, #1000156, #1000186, #1000207, #1000238, #1000262, #1000263, #380, #389, #683, #1238, #1331, #1635, #1645, #1715, #1729, #1744, #1783, #1839, #1869, #1885, #1890, #1902, #1918, #1919, #1924, #1925, #1946, #1964, #1991, #2131, #2233, #2342, #2348, #2408, #2459, #2499, #2523, #2572, #2582, #2602, #2614, #2615, #2675, #2710, #2745, #2763, #2816, #2830, #2834, #2878, #2879, #2887, #2888, #2901, #2911, #2912, #2922, #2937, #2938, #2942, #2951, #2955, #2957, #2961, #2964, #2965, #2974, #2975, #2989, #2990, #3002, #3055, #3070, #3087, #3135, #3139, #3173, #3182, #3184, #3200, #3213, #3214, #3221, #3243, #3251)
on 2011-03-24 20:18 *
By Iulian Dragos
Updating tickets (#1000199, #1000200, #1000201, #1000204, #1000205, #1000209, #1000210, #1000211, #1000212, #1000215, #1000217, #1000218, #1000220, #1000222, #1000226, #1000227, #1000228, #1000230, #1000231, #1000232, #1000233, #1000235, #1000236, #1000237, #1000239, #1000240, #1000241, #1000242, #1000243, #1000244, #1000248, #1000249, #1000252, #1000253, #1000254, #1000255, #1000256, #1000258, #1000259, #1000032, #1000059, #1000062, #1000163, #1000197, #1000216, #1000221, #1000224, #1000121, #1000175, #1000219, #1000251, #1000069, #1000195, #1000213, #1000223, #1000006, #1000021, #1000038, #1000048, #1000051, #1000052, #1000075, #1000103, #1000109, #1000115, #1000119, #1000156, #1000186, #1000207, #1000238, #1000262, #1000263, #380, #389, #683, #1238, #1331, #1635, #1645, #1715, #1729, #1744, #1783, #1839, #1869, #1885, #1890, #1902, #1918, #1919, #1924, #1925, #1946, #1964, #1991, #2131, #2233, #2342, #2348, #2408)
