-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Remove file count limitation in server build #54992
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The server protocol used to enforce a max of 65,535 files passed to the compilation. This isn't due to any limitation in the compiler but instead a guard against a bug in one of our internal build systems. It provided graceful failure when a build authoring bug caused the contents of the file system to be passed to the compiler. That is no longer an issue and the existing limit is blocking real customer scenarios. Should it become an issue again there is code we could insert into the customer targets to add a similar guard. I thought for a bit on what a new limit should be and eventually decided there wasn't a reasonable one. The compiler server already has a protocol guard on the size of the message payload. The batch compiler generally doesn't enforce limits of this nature, insead we attempt to scale to the build requested by the user. Hence just removed the limitation entirely closes dotnet#54775
@roslyn-compiler PTAL small bug fix |
cston
approved these changes
Jul 20, 2021
RikkiGibson
approved these changes
Jul 20, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you try running a build with more than 2^16 source files?
Yep. It actually works better than I would expect |
ghost
added this to the Next milestone
Jul 22, 2021
tombuildsstuff
added a commit
to hashicorp/pandora
that referenced
this pull request
Jul 22, 2021
…5 source files in a project This is necessary since there's sufficient files when generating all versions of all the things that we exceed this limit. This is tracked in the upstream issue dotnet/roslyn#54775 and has been fixed in dotnet/roslyn#54992 (but not yet released). Ultimately this fixes #129
tombuildsstuff
added a commit
to hashicorp/pandora
that referenced
this pull request
Jul 22, 2021
…5 source files in a project This is necessary since there's sufficient files when generating all versions of all the things that we exceed this limit. This is tracked in the upstream issue dotnet/roslyn#54775 and has been fixed in dotnet/roslyn#54992 (but not yet released). Ultimately this fixes #129
333fred
added a commit
to 333fred/roslyn
that referenced
this pull request
Jul 23, 2021
* upstream/main: (249 commits) Switch back queue name to default (dotnet#55064) Fix 'code model' with file scoped namespaces Map documents to be reanalyzed back from compile-time to design-time documents (dotnet#55054) Update MSBuild Workspace test projects target framework Enable CA1069 for ErrorCode and MessageID (dotnet#54695) Dev16->17 updates Update global.json Record completion of "parameterless struct constructor" feature (dotnet#55049) Generalize rude edit messages to be applicable to both Hot Reload and EnC (dotnet#55012) Update azure-pipelines-official.yml Update azure-pipelines-integration.yml Merge pull request dotnet#54992 from jaredpar/so-big Parameterless struct constructors: Remaining work items (dotnet#54811) Update docs/wiki/Diagnosing-Project-System-Build-Errors.md update queue name Dev16->17 changes Fix test Fix 'move type' with file scoped namespaces Fix 'match folder and namespace' with file scoped namespaces Log NFW ...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The server protocol used to enforce a max of 65,535 files passed to the
compilation. This isn't due to any limitation in the compiler but
instead a guard against a bug in one of our internal build systems. It
provided graceful failure when a build authoring bug caused the contents
of the file system to be passed to the compiler.
That is no longer an issue and the existing limit is blocking real
customer scenarios. Should it become an issue again there is code we
could insert into the customer targets to add a similar guard.
I thought for a bit on what a new limit should be and eventually decided
there wasn't a reasonable one. The compiler server already has a
protocol guard on the size of the message payload. The batch compiler
generally doesn't enforce limits of this nature, insead we attempt to
scale to the build requested by the user. Hence just removed the
limitation entirely
closes #54775