You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The symptom: //> using exclude foo does not stop scanning inside of foo, so if foo contains project.scala with directives, then it will evaluate the directives in foo/project.scala and even try to compile code.
(when i remove foo/project.scala then code compilation is excluded in foo as expected)
Here was an initial idea for a solution:
well, i would assume exclude should tell scala-cli to never even look inside that directory. Currently (if the excluded subdirectory has project.scala) it will try to typecheck my scala code in that subdirectory - and check using directives (such as reporting unresolvable library dependencies).
I would imagine the solution being an ahead of time scan for exclude before evaluating other settings/running compiler.
if that is too complex or performance sensitive - then perhaps warn about these semantics in the documentation
So during the Scala tooling spree - @MaciejG604 pointed me towards CrossSources.scala, and the culprit is "finding first project.scala file in flattened inputs" - which often is likely this nested project that should be excluded.
The solution is instead to find the most-outer project file
The symptom:
//> using exclude foo
does not stop scanning inside offoo
, so iffoo
containsproject.scala
with directives, then it will evaluate the directives infoo/project.scala
and even try to compile code.(when i remove
foo/project.scala
then code compilation is excluded infoo
as expected)Here was an initial idea for a solution:
Originally posted by @bishabosha in #3385
The text was updated successfully, but these errors were encountered: