Clarify defaultRefAssemblies list capacity in AddType.cs

[xtqqczze]

PR Summary

• Clarify calculation of defaultRefAssemblies initial list capacity.
• Assert if list capacity is increased as a result of a resize.

PR Context

InitDefaultRefAssemblies may initialize a list too small to hold the reference assemblies distributed with netcoreapp5.0, which may result in an expensive reallocation of the internal array.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[vexx32]

Question - is there a way to verify that assertion in a way that can be tested in CI? Debug asserts are great but can cause annoying crashes which seems to be more likely to be a nuisance in a case like this.

Can we add a unit test in C# to verify this instead, so we get a clear test failure without generating broken build artifacts? Doubly so if we're expecting this number to change in future, we should be very careful about using a debug assert here, which will render this functionality entirely unusable in debug builds and I'm not sure will even show up in CI at all.

[iSazonov]

I guess the value depends only on .Net version and we will catch the exception only after moving to new version and only for local debug builds.

Also we can count refs at design time - see code after # publish reference assemblies in Build.psm1

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

[ghost]

Hello @iSazonov!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[ghost]

🎉v7.1.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes