This repository has been archived by the owner on Feb 3, 2018. It is now read-only.
Make ProjectAnalyzer an argument to SourceManager.GetManifestAndLock() #195
Assignees
Labels
Comments
sdboyer
added a commit
that referenced
this issue
Apr 1, 2017
This was really always the intended model - there's no reason a SourceManager needs to be permanently coupled with just one analyzer. It's perfectly sufficient to provide one as an argument to the relevant methods. Fixes #195.
krisnova
pushed a commit
to krisnova/dep
that referenced
this issue
Apr 21, 2017
This was really always the intended model - there's no reason a SourceManager needs to be permanently coupled with just one analyzer. It's perfectly sufficient to provide one as an argument to the relevant methods. Fixes sdboyer/gps#195.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There's only one method for which the
ProjectAnalyzeractually gets used -SourceManager.GetManifestAndLock(). There's really no reason that it has to be injected into the source manager as an argument toNewSourceManager(); it could just be passed as a parameter to that one method.In addition to cleaning up some internal interfaces, the big advantage here is that a
*sourceMgrinstance is no longer bound to operate with a singleProjectAnalyzer. There's no current use case where this really matters right now, but this was a nasty coupling between solvers (whose correct operation is predicated on only ever having the one analyzer) and the source managers.We can also eliminate
SourceManager.AnalyzerInfo()as part of this.The text was updated successfully, but these errors were encountered: