Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use directory-scoped ALCs to load analyzers in .NET Core #55098

Merged
merged 29 commits into from
Aug 23, 2021

Conversation

RikkiGibson
Copy link
Contributor

Resolves #52177

@AraHaan
Copy link
Member

AraHaan commented Jul 27, 2021

So when this gets merged will this by chance make it in .NET 6 in time?

@RikkiGibson
Copy link
Contributor Author

Yes but probably not till RC1.

@AraHaan
Copy link
Member

AraHaan commented Jul 27, 2021

Alright, I get the daily RC1 builds so hopefully it lands on those soon.

Copy link
Member

@jaredpar jaredpar left a comment

Choose a reason for hiding this comment

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

The loader should only be loading analyzer assemblies that are explicitly passed to the compiler.

RikkiGibson and others added 2 commits August 5, 2021 11:27
@RikkiGibson RikkiGibson requested a review from a team as a code owner August 5, 2021 18:27
src/Compilers/Test/Core/AssemblyLoadTestFixture.cs Outdated Show resolved Hide resolved
analyzer.GetType().GetMethod("Method")!.Invoke(analyzer, new object[] { sb });
Assert.Equal(ExecutionConditionUtil.IsCoreClr ? "1" : "42", sb.ToString());
}

Copy link
Member

Choose a reason for hiding this comment

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

One test I think is missing is firing up two different DefaultAnalyzerAssemblyLoader and verifying they can load different assemblies that have the same simple name. That is effectively what the compiler server is going to be doing.

Copy link
Contributor Author

@RikkiGibson RikkiGibson Aug 19, 2021

Choose a reason for hiding this comment

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

Does this comment describe a different scenario than what is covered in AssemblyLoading_MultipleVersions (where 'Delta1' and 'Delta2' have the same simple name)?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. In that test you're creating one DefaultAnalyzerAssemblyLoader and loading two different versions of Delta into it and verifying that one fails. I'm saying create two DefaultAnalyzerAssemblyLoader instances and load Delta1 into the first and Delta2 into the second. That is effectively how long lived hosts on .NET Core will work (new loader per compilation) and want to verify that it's working and that the correct Assembly is loaded into each context

Copy link
Member

Choose a reason for hiding this comment

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

Actually one other test you need is loading Delta1 and Delta2 into the same DefaultAnalyzerAssemblyLoader but from different directories. That should work just fine now. That is essentially our core analyzers with conflicting dependencies case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have AssemblyLoading_MultipleVersions to test loading different versions of the same assembly into one loader. I added a test AssemblyLoading_MultipleVersions_MultipleLoaders to do the same but with each version in a different loader.

Copy link
Member

@jaredpar jaredpar left a comment

Choose a reason for hiding this comment

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

Minor feedback.

analyzer.GetType().GetMethod("Method")!.Invoke(analyzer, new object[] { sb });
Assert.Equal(ExecutionConditionUtil.IsCoreClr ? "1" : "42", sb.ToString());
}

Copy link
Member

Choose a reason for hiding this comment

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

Yes. In that test you're creating one DefaultAnalyzerAssemblyLoader and loading two different versions of Delta into it and verifying that one fails. I'm saying create two DefaultAnalyzerAssemblyLoader instances and load Delta1 into the first and Delta2 into the second. That is effectively how long lived hosts on .NET Core will work (new loader per compilation) and want to verify that it's working and that the correct Assembly is loaded into each context

return loadContext.LoadFromAssemblyName(name);
}

internal static class TestAccessor
Copy link
Member

Choose a reason for hiding this comment

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

Why did you opt to have a TestAccessor here vs. just adding an internal method on DefaultAnalyzerAssemblyLoader?

Copy link
Contributor Author

@RikkiGibson RikkiGibson Aug 20, 2021

Choose a reason for hiding this comment

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

I wanted people to feel bad about ever accessing this in the implementation. I was attempting to imitate TestAccessor patterns in ChangedText.cs, SegmentedArray`1.cs, etc.


namespace Microsoft.CodeAnalysis.Test.Utilities
{
public sealed class AssemblyLoadTestFixture : IDisposable
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a really nice change!

Copy link
Contributor

@chsienki chsienki left a comment

Choose a reason for hiding this comment

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

Couple nits, but otherwise looks great!

@RikkiGibson RikkiGibson enabled auto-merge (squash) August 23, 2021 18:36
@RikkiGibson RikkiGibson merged commit 99f45b7 into dotnet:main Aug 23, 2021
@ghost ghost added this to the Next milestone Aug 23, 2021
@RikkiGibson RikkiGibson deleted the alc branch August 23, 2021 19:04
@AraHaan
Copy link
Member

AraHaan commented Aug 23, 2021

So basically this did not make it in time for the .NET 6 rc.1 daily builds?

CyrusNajmabadi pushed a commit to CyrusNajmabadi/roslyn that referenced this pull request Aug 24, 2021
@jaredpar
Copy link
Member

So basically this did not make it in time for the .NET 6 rc.1 daily builds?

This will make 17.0 Preview 4 which should be in the .NET 6 SDK RC1 builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Analyzer host process fails to load analyzers correctly when building in parallel
7 participants