Incremental build refactor #10538
Incremental build refactor #10538
Conversation
|
If it's OK to use arrays and mutation now, would it also make sense to incorporate changes from #9259 somehow? |
The nature of incremental builder is mutable state. The changes made in this PR are implementation details and don't bleed out of the API. Though I would want to make |
|
This is now ready. :) |
| @@ -979,7 +980,7 @@ type IncrementalBuilder(tcGlobals, frameworkTcImports, nonFrameworkAssemblyInput | |||
| computeStampedFileName cache ctok slot fileInfo (fun slot fileInfo -> | |||
| let prevSemanticModel = | |||
| match slot with | |||
| | 0 -> initial | |||
| | 0 (* first file *) -> initial | |||
There was a problem hiding this comment.
Could a named literal work better than a comment here?
There was a problem hiding this comment.
We could, but I think it's fine that we have the comment here. At some point, we will do another round of refactoring here, but it will be much easier to do now.
* Initial incremental build refactor * Get previous slot * Fixed build * Fixed timestamp max * Updating surface area * Fixing last test * Just return true * Add minor TODO * Change value name to something more coherent * Fixing test
This is the second and hopefully the final attempt at refactoring incremental build to simply use arrays and mutations instead of the framework that was built for it.
The goal here is not to gain performance; but to improve the readability and flexibility without being constrained by the previous framework.