The `//> using exclude` directive is silently ignored when declared in any file other than `project.scala`

[Gedochao]

Version(s)
1.5.4 and 4ab3227

Describe the bug
If the //> using exclude (..) directive is declared anywhere but project.scala, it gets ignored completely, with no warning.
While we do not want it declared in other files (and that is intended), we should communicate it better in our docs as well as actually warn users about it being ignored.
The current behaviour is very confusing.

To Reproduce
Try to use the //> using exclude directive in any file other than project.scala.

Expected behaviour

• clear explanation in the docs
• a proper warning when //> using exclude is declared wrongly

[bishabosha]

another example that doesn't work, if //> using exclude foo directive is in a project.scala file, but the excluded foo dir also has a project.scala

• basically makes it impossible to have an "examples" scala-cli project (that depends on a published version of the parent) in a nested directory - you have to put the main project and examples in sibling directories
• maybe this is less important now that test scope can have main methods invoked from command-line

[Gedochao]

another example that doesn't work, if //> using exclude foo directive is in a project.scala file, but the excluded foo dir also has a project.scala

• basically makes it impossible to have an "examples" scala-cli project (that depends on a published version of the parent) in a nested directory - you have to put the main project and examples in sibling directories
• maybe this is less important now that test scope can have main methods invoked from command-line

@bishabosha I am not sure I quite understand your use case. How would you suggest it should work?

[bishabosha]

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

[Gedochao]

Ah, now I understand.
Yup, agreed... We'd have to stop scanning for exclude as soon as it is found. Might be tricky.
I do think that's a separate issue, though.
@bishabosha can you raise it, so it doesn't get lost?