settings.sourcepath redirected to Ysourcepath #4
Conversation
|
Integrated your changes from fa2015f into pullrequest/reflection. Could you, please, submit the upcoming stuff (if any) against pullrequest/reflection (it's been updated today, so I can't merge cleanly the patches that are made against yesterday's version)? |
|
@retronym: There are two sides to the compatibility problem: the command line options and the internal settings.sourcepath. The -sourcepath command-line option and the sourcepath in the scaladoc ant task point to the doc-source-path as they should, but add a deprecation warning. Same thing for scalac, -sourcepath points to -Ysourcepath + warning. On the other hand I'm not sure what to do about the settings.sorucepath, which may be used by external programs in both the scalac and scaladoc context. That's why I opted for immediately throwing an exception, so everyone updates their use of sourcepath to either Ysourcepath of docSourcePath. But now it's wired to Ysorucepath and theoretically we could rewire it to docSorucePath for scaladoc settings. What's your take on that? @xeno-by: Sorry I didn't know what branch to file the pull request against. I'll send pull reqs against pullrequest/reflection from now on. |
|
Can you explain shortly why we need two different source paths, and why 'sourcepath' should go? If we needed a second one, isn't it easier to simply add it, and leave the old one in place, with the previous semantics? |
|
@dragos: We basically had two semantics added to sourcepath and we actually wanted to use either one or the other, but not both at the same time. The motivation to remove sourcepath came when the scaladoc for the reflection build started failing because we used -sourcepath as -doc-source-path but at the same time the typer picked up the option as "please bootstrap the library" -- and the typer was failing while bootstrapping. |
|
Shouldn't we have a 'bootstrap the library' option then? |
|
|
|
|
|
Now I see that there was a third player in the I think it would make sense to disambiguate between scalac's |
|
Hm, the presentation compiler relies on the standard compiler semantics of |
1 similar comment
|
Hm, the presentation compiler relies on the standard compiler semantics of |
broke out findMembers as a separate operation to streamline the code. findMember itself still needs to be optimized.
First of all, GIL should only apply to runtime reflection, because noone is going to run toolboxes in multiple threads: a) that's impossible, b/c the compiler isn't thread safe, b) ToolBox api prevents that. Secondly, the only things in symbols which require synchronization are: 1) info/validTo (completers aren't thread-safe), 2) rawInfo and its dependencies (it shares a mutable field with info) 3) non-trivial caches like in typeAsMemberOfLock If you think about it, other things like sourceModule or associatedFile don't need synchronization, because they are either set up when a symbol is created or cloned or when it's completed. We can say that symbols can be in four possible states: 1) being created, 2) created, but not yet initialized, 3) initializing, 4) initialized. single thread. #2 and #4 don't need synchronization either, because the only mutation symbols in runtime reflection can undergo is init. #3 is dangerous and needs protection.
First of all, GIL should only apply to runtime reflection, because noone is going to run toolboxes in multiple threads: a) that's impossible, b/c the compiler isn't thread safe, b) ToolBox api prevents that. Secondly, the only things in symbols which require synchronization are: 1) info/validTo (completers aren't thread-safe), 2) rawInfo and its dependencies (it shares a mutable field with info) 3) non-trivial caches like in typeAsMemberOfLock If you think about it, other things like sourceModule or associatedFile don't need synchronization, because they are either set up when a symbol is created or cloned or when it's completed. We can say that symbols can be in four possible states: 1) being created, 2) created, but not yet initialized, 3) initializing, 4) initialized. single thread. #2 and #4 don't need synchronization either, because the only mutation symbols in runtime reflection can undergo is init. #3 is dangerous and needs protection.
First of all, GIL should only apply to runtime reflection, because noone is going to run toolboxes in multiple threads: a) that's impossible, b/c the compiler isn't thread safe, b) ToolBox api prevents that. Secondly, the only things in symbols which require synchronization are: 1) info/validTo (completers aren't thread-safe), 2) rawInfo and its dependencies (it shares a mutable field with info) 3) non-trivial caches like in typeAsMemberOfLock If you think about it, other things like sourceModule or associatedFile don't need synchronization, because they are either set up when a symbol is created or cloned or when it's completed. We can say that symbols can be in four possible states: 1) being created, 2) created, but not yet initialized, 3) initializing, 4) initialized. single thread. #2 and #4 don't need synchronization either, because the only mutation symbols in runtime reflection can undergo is init. #3 is dangerous and needs protection.
settings.sourcepath redirected to Ysourcepath
checkin build: https://scala-webapps.epfl.ch/jenkins/job/scala-checkin-manual/79/console
Review by @dragos.