Watch registration on non-compiled libraries leaks stack trace

[rodinaarssen]

Upon starting a REPL, file system watches are registered in the interest of automatic reloading of changed modules; more specifically, for each directory in the PathConfig's srcs and libs. For dependencies for projects that are open in the IDE, the dependency to a maven artifact is rewritten to the local project (as intended), which results in a local project's target/classes ending up in libs (again, as intended). This works fine if the project was ever compiled (and, hence, target/classes exists), but for projects that lack previous compilation, this results in an attempt to register a watch on a non-existent location. This is not possible, and thus fails, leaking a stack trace to the user.

Rascal-lsp Unknown
Rascal 0.41.0-RC47-SNAPSHOT
Rascal search path:
- |std:///|
- |file:///c:/test/test-workspace/test-lib/src/main/rascal|    
- |file:///C:/test/test-workspace/test-project/src/main/rascal|
- |jar+file:///C:/test/usethesource.rascalmpl-0.13.0-head/assets/jars/rascal-lsp.jar!/|
Rascal classloader path:
- |file:///C:/test/test-workspace/test-project/target/classes| 
PathConfig messages:
[INFO]    /C:/test/test-workspace/test-project/:0:0: Rascal version:0.41.0-RC47-SNAPSHOT
[INFO]    /C:/test/test-workspace/test-project/pom.xml:0:0: Redirected: org.rascalmpl:test-lib:0.1.0-SNAPSHOT to: |project://test-lib|
Failed to register watch for |file:///test/test-workspace/test-project/target/classes|
java.nio.file.NoSuchFileException: C:\test\test-workspace\test-project\target
        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)    
        at java.base/sun.nio.fs.WindowsException.asIOException(WindowsException.java:112)
        at java.base/sun.nio.fs.WindowsWatchService$Poller.implRegister(WindowsWatchService.java:366)
        at java.base/sun.nio.fs.AbstractPoller.processRequests(AbstractPoller.java:265)
        at java.base/sun.nio.fs.WindowsWatchService$Poller.run(WindowsWatchService.java:596)
        at java.base/java.lang.Thread.run(Thread.java:829)

There are two things to consider here:

• There is a leaking stack trace
• There is no watch on the target/classes of the library project. This means that even after compilation of this project, changes to these files will not be picked up.