TextWriter.Synchronized does this and isn't missing APIs, which can cause derived methods to not be called. Test added.
Commit migrated from 0b868a47b4
* Configuration changes so that System.Reflection.Emit may compile against
netstandard2.0
* Adding NS2.0 config for System.Reflection.Emit.Lightweight
* Fixing netfx vertical
* Addressing PR Feedback
* Fixing mscorlib facade generation now that there are a few type
conflicts
* Add back Ref.Emit packages
These packages all needed the following workarounds:
1. Matching not-supported implementation assemblies for netstandard1.x
2. Not support implementation for AOT frameworks
3. Ensure we don't add API to old frameworks (eg: UAP10.0.16299, desktop) or frameworks compatible with those (netstandard2).
Commit migrated from 1e72f59677
* Moving sign.builds to run on full .NET Framework.
MicroBuild signing doesn't work when MSBuild is running on .NET Core. So move the signing piece to use MSBuild on full framework.
* Flow SignType property through to sign.builds.
Commit migrated from b9e62080ed
SocketAsyncEventArgs has a few issues with ExecutionContext, presumably stemming from the fact that capturing ExecutionContext in .NET Framework is not a cheap operation. As a result, when this code was written, it was optimized for avoiding calls to ExecutionContext.Capture. The SAEA tries to hold onto a captured ExecutionContext for as long as possible, only re-capturing when either the SAEA is used with a different socket instance or when an event handler is changed. That has several problems, though. First, it largely violates the purpose of ExecutionContext, which is to flow information from the point where the async operation begins to the continuation/callback, but if the context is only being captured when the Socket or handler is changed, then the context isn't actually tied to the location where the async operation begins, and that means that data like that in an AsyncLocal doesn't properly flow across the async point. Second, it means that the SocketAsyncEventArgs (the whole purpose of which is to cache it) can end up keeping state in an ExecutionContext alive well beyond when it should be kept alive, because the SocketAsyncEventArgs is holding onto the ExecutionContext instance until either the Socket or handler is changed.
This commit fixes this behavior. Since ExecutionContext.Capture in .NET Core is relatively cheap (no allocation, primarily just a ThreadStatic access), we now just always capture the context when starting an operation, and then clear it out when completing the operation.
Commit migrated from 851a53bee2
Convert.FromBase64() had a subtle bug where an illicit
second padding character at the end of the string caused
the decode to "succeed" by dropping the fifth to
last character.
We inadvertently fixed this bug while optimizing that
api in .NetCore 2.1. Adding test to document bug and
ensure we don't regress.
Details in https://github.com/dotnet/corefx/issues/30793
Commit migrated from f1065c7cf0
Fix failing tests & remove noisy output loggings
Use common threadculture and remove unused files
Cleanup test codebase & delete unused files
Remove resource from turd assembly
Auto format documents
Commit migrated from 78bf9d7974
* Update the OptionalTooling to work on .NET Core MSBuild.
The official build broke because I moved the Windows build on to .NET Core MSBuild. We have some OptionalTooling that only gets restored during the official build, and the current approach (using project.json) doesn't work on .NET Core MSBuild. So migrating the tooling to use normal MSBuild PackageReferences.
Fixdotnet/corefx#30758
* Respond to PR feedback.
Upper case each section of the package name in the MSBuild version property.
Commit migrated from 6cec67359b
Getting the current cursor position involves writing a particular escape sequence to stdout and then reading/parsing the response. In case the terminal doesn't support the sequence, we use `tcsetattr` to tell the terminal set set c_cc[MIN] to 0 and c_cc[VTIME] to 10; this makes it so that if no input is received within one second, we'll give up on reading the response. If we didn't do this and no response came back, or if a faulty response came back such that we would otherwise just sit there waiting for something that would never come, the console could end up hanging until the user typed the expected sequence.
However, this timeout can cause problems when the terminal is separated by a slow network connection from the console logic, in which case the CPR can time out and the response can end up not only being echoed to the screen, but also interpreted as user input.
This change tracks whether we've ever received a successful CPR response. Until we have, it keeps using 0 for c_cc[MIN], i.e. the minimum number of chars we need to read, such that it relies on the timeout firing and we return when either we've read at least one byte or the timer fires. Once we've successfully read a CPR response, for all future requests, we set c_cc[MIN] to 1. With that, we'll still return once at least one byte is received, but the timer won't start until then, which helps avoid this issue with slow network connections.
Commit migrated from dd8449ded9
* RegexParser & optionsstack ref
* Add test coverage for Group.Synchronized
* Adjust options mode test case
* Add inline comment '#' test branch
* Add comments
* Replace manual ToLower calls by Span.ToLower
* Make applicable fields readonly in parser
* Change to Assert to reduce an if check in one branch
* Code formatting
* Avoid string allocation when IgnoreCase set
Prefix patterns which are passed to RegexBoyerMoore are already
lowercased by the parser. Remove the redundant ToLower() call and assert
the patterns lowercase state
* Add surrogate pair positive & negative tests
* Add test cases for rtl anchor
Commit migrated from 2f259de0bc
* Corefx Windows build on .NET Core MSBuild
Note: Need to move to the 3.0 SDK because the DiaSymReader.Native shipped in .NET Core's shared framework is out of date. See https://github.com/dotnet/core-setup/issues/4291.
* Workaround .NET Core MSBuild bug.
MSBuild on .NET Core doesn't support non-string resources. However, the ResourceManager tests need to test this scenario. Using the .NET Framework's resgen.exe during the build until the MSBuild bug is fixed.
* Update BuildTools to 2.2.0-preview1-02928-01
Commit migrated from 50ba6a21d8
This moves all the managed pieces of Internal/Cryptography/Pal.OSX/CertificatePal.cs
which are not platform-specific into a separate file to allow them to be used in Mono.
Commit migrated from a69961ae69
* Fix ImageFormat.ToString by using it's Guid when comparing to static ImageFormats
* Add Image.RawFormat.ToString test
* Skip test on NETFX
* Address PR feedback
Commit migrated from aaaf87bbdd
* Fix FontFamily.Name performance by using span and calling the interop
code with char pointer
* PR Feedback
* Remove added System.Memory reference
Commit migrated from 5d9a3ccdbd
