Rather than the cache being a ProjectId -> cached driver map, we instead just have the object holding the cached driver held directly by the ProjectState.
Rather than clearing out the cached driver once we think we won't need it, we just continually refresh the cached driver with the latest version. This simplifies the logic and also ensures we won't ever clear something out that we would need later, but still keeps us from holding onto old state.
Rather than explicitly clearing out the initialized driver when we have to rerun generators, we keep it around.

Change logic for how we cache GeneratorDrivers to avoid initialization

98fa825

This makes a few general changes to how we cache drivers so we don'tre-initialize them multiple times when we're first loading a solution.1. Rather than the cache being a ProjectId -> cached driver map,   we instead just have the object holding the cached driver held   directly by the ProjectState.2. Rather than clearing out the cached driver once we think we won't   need it, we just continually refresh the cached driver with the   latest version. This simplifies the logic and also ensures we won't   ever clear something out that we would need later, but still   keeps us from holding onto old state.3. Rather than explicitly clearing out the initialized driver when we   have to rerun generators, we keep it around.

jasonmalinowski self-assigned this

Nov 19, 2025

github-actionsbot added the Area-IDE label

Nov 19, 2025

dotnet-policy-servicebot added the VSCode label

Nov 19, 2025

ToddGrun reviewed

Nov 19, 2025

View reviewed changes

...Portable/Workspace/Solution/SolutionCompilationState.RegularCompilationTracker_Generators.cs

		// 1. If some other fork of this Solution needs a GeneratorDriver created, it'll have one that's probably more update to date.
		// This is obviously speculative -- if it's a really old Solution fork it might not help, but can't hurt for the more common cases.
		// 2. It ensures that we're not holding an old GeneratorDriver alive, which itself may hold onto state that's no longer applicable.
		this.ProjectState.GeneratorDriverCache.UpdateCacheWithForGeneratorDriver(generatorDriver);

Copy link

Contributor

ToddGrunNov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

WithFor

nit: name is odd

CyrusNajmabadi approved these changes

Nov 19, 2025

View reviewed changes

...e/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverInitializationCache.cs

		publicvoidUpdateCacheWithForGeneratorDriver(GeneratorDriverdriver)
		{
		ImmutableInterlocked.TryRemove(ref_driverCache,projectId,out_);
		_driverCache=AsyncLazy.Create(driver);

Copy link

Member

CyrusNajmabadiNov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Cute. Definitely doc this field to explain this will happen. Ah. I see you did doc this well

src/Workspaces/Core/Portable/Workspace/Solution/SolutionCompilationState.cs

		// Clear out the cache of any previously initialized GeneratorDriver. Otherwise we might reuse a
		// driver which will not count as a new "run" in some of our unit tests. We have tests that very explicitly count
		// and assert the number of invocations of a generator.
		GeneratorDriverCache.EmptyCacheForProject(projectId);