{"push_id":1133109443,"size":20,"distinct_size":3,"ref":"refs/heads/TestNewCoreCLRPackages","head":"f82d84eb2e2f261bdf765aa87f83c16ff99ae7d3","before":"224b1c49ffdb39ce17e73c8ca50c42d3ccf53fdd","commits":[{"sha":"217289492a53b9972a9c0f9d0ce3503c422fe601","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Remove broken BUILDTOOLS_OVERRIDE_RUNTIME support\n\nThe layout of CLI has changed and the logic resulted in a non working\nCLI and errors during init-tools.sh","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/217289492a53b9972a9c0f9d0ce3503c422fe601"},{"sha":"02f40870f59eda6dae5c55550670dc4b433cb59e","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Write msbuild.[wrn|err] logs on Unix","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/02f40870f59eda6dae5c55550670dc4b433cb59e"},{"sha":"1d8bac52febbaf4f1cc626cc8ef4c030054e92ef","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Remove some dead code","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/1d8bac52febbaf4f1cc626cc8ef4c030054e92ef"},{"sha":"d04f336f215e935aaef47f50db6afe92539a7a44","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Disable API Compat on Unix\n\nThere are some bugs when this is run on Unix due to file casing\nissues. Now that MSBuild will actually catch these and produce errors,\nwe need to disable this task.","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/d04f336f215e935aaef47f50db6afe92539a7a44"},{"sha":"fdd2dedd93e20d0ff7563cb143b32adb11f7cdc2","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Update BuildTools version\n\nThis contains a lot of fixes for building on Unix and updates the tool\nruntime be an RC3 build.\n\nFixes #8815\nFixes #8386\nFixes #8495","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/fdd2dedd93e20d0ff7563cb143b32adb11f7cdc2"},{"sha":"66ed6f0c6f0aacf937cadc55b0ad2537496499ff","author":{"name":"Gaurav Khanna","email":"80ee79439997d5ef552d3a15b433965545c2ec79@microsoft.com"},"message":"Reenable ALC test","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/66ed6f0c6f0aacf937cadc55b0ad2537496499ff"},{"sha":"eecacdc6432036b8e44efa29f3a06d8c1c9cfeca","author":{"name":"Stephen Toub","email":"b60ab4ec0ae5032e51dd285ac67105c722f075d3@microsoft.com"},"message":"Remove implicit casts from ValueTask<T>\n\nThe C# team is considering adding a feature to C# that would allow for arbitrary types to be used as the return type from async methods, with ValueTask<T> being a key motivator.  As part of this, they're considering overload resolution in a situation like:\n```C#\nasync Task Method(Func<Task<int>> f);\n...\nMethod(async () =>\n{\n    await Blah();\n    return 3;\n});\n```\nwhere a developer previously had a method that accepted a ```Func<Task<int>>```, and then with ```ValueTask<T>``` adds an overload like:\n```C#\nasync Task Method(Func<ValueTask<int>> f);\n```\nPresumably the ```ValueTask<int>``` overload should be preferred in this case.  However, if a developer added another overload:\n```C#\nasync Task Method(Func<IAsyncOperation<int>> f);\n```\n(assuming IAsyncOperation could be used in a return position), we would not want that one preferred.  Thus, if this situation should not be considered ambiguous and require the developer to cast/type at the call site to specify which overload should be used (which might be the right answer), there would need to be some tie-breaking mechanism.\n\nThe current favorite mechanism of the rest of the C# design team besides me is using implicit conversions as the way to signal this to the compiler, such that if there's an implicit conversion from ```B``` to ```A``` and overloads that take a ```Func<B>``` and ```Func<A>```, ```Func<B>``` would be preferred.  For this to work with ```Task<T>``` and ```ValueTask<T>```, ```ValueTask<T>``` would need an implicit cast to ```Task<T>``` and could not have one in the other direction from ```Task<T>``` to ```ValueTask<T>```.\n\nToday, ```ValueTask<T>``` has an implicit cast from ```Task<T>``` to ```ValueTask<T>```, just as it has an implicit cast from ```T``` to ```ValueTask<T>```.  A ```ValueTask<T>``` is just a wrapper for both a ```T``` or a ```ValueTask<T>``` (it has a field for each), and so this is just a quick way of creating that wrapper from either of the two members that make up the discriminated union.  In this direction, no information is lost, there are no heap allocations, etc.\n\nIn the other direction, implicitly casting a ```ValueTask<T>``` to a ```Task<T>``` may or may not be allocating: if the ```ValueTask<T>``` was created from a ```Task<T>```, then implicitly casting to a ```Task<T>``` would just return the stored task.  But if the ```ValueTask<T>``` was created from a value (which is the most common case in scenarios where ```ValueTask<T>``` is used, as it's used in places where you expect synchronous completion and thus to have a value rather than a task), then implicitly casting to a ```Task<T>``` would result in needing to allocate that task as part of the implicit cast, leading to implicit and silent allocations.\n\nI very much dislike the idea of adding such an implicit cast from ```ValueTask<T>``` to ```Task<T>```.  However, by having the implicit cast in the opposite direction, we shut the door on being able to add such an implicit cast in the future for such overload resolution purposes.  Thus, this commit removes the current implicit casts in order to allow us to decide to add back either (or both) directions in the future.","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/eecacdc6432036b8e44efa29f3a06d8c1c9cfeca"},{"sha":"704f56d101ccee3e6774abc313370a226093e43f","author":{"name":"Stephen Toub","email":"b60ab4ec0ae5032e51dd285ac67105c722f075d3@microsoft.com"},"message":"Fix ValueTask<T>.ToString behavior with null results\n\nValueTask<T>'s ToString implementation doesn't special-case null results today, under the argument that it's just a wrapper for a T, and so if you do \"new ValueTask<string>((string)null).ToString()\", that should behave similarly to \"((string)null).ToString()).  But, of course, that means NullReferenceExceptions can emerge from calling ToString on a value type, and that code like \"default(ValueTask<SomeRefType>).ToString() will null ref, which is likely unexpected.\n\nThis commit changes the behavior of ToString to be less complicated and to handle nulls: if the ```ValueTask<T>``` has a non-null result (either from the ```Task<T>``` or the ```T```), the result's ToString is returned, otherwise string.Empty is returned.","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/704f56d101ccee3e6774abc313370a226093e43f"},{"sha":"3e3ab10bc37fb4379b7e38366ca0978ce8efa4b0","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Support building on all supported distros\n\nWith the updated buildtools, we should now be able to build on all the supported distros:\n\n - Centos 7\n - Fedora 23\n - openSUSE 13.2\n - RHEL 7.2\n - Ubuntu 14.04\n - Ubuntu 16.06\n\nSince the CLI support for some of these is still comming online, I\nhave published custom versions to our own Azure Blob storage that we\ncan download. Once CLI has real builds ready, we can move back to\ntheir built binaries.\n\nI also cleaned up how we compute the RID for the tools to restore.","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/3e3ab10bc37fb4379b7e38366ca0978ce8efa4b0"},{"sha":"a62c9fff1f768422b645fe03ff1153852d87247e","author":{"name":"Stephen Toub","email":"b60ab4ec0ae5032e51dd285ac67105c722f075d3@microsoft.com"},"message":"Merge pull request #8915 from gkhanna79/EnableALCTest\n\nReenable ALC test","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/a62c9fff1f768422b645fe03ff1153852d87247e"},{"sha":"a9df42d5aaf9de880b52d48a717dcdeecde452c5","author":{"name":"Eric St. John","email":"5cba59b6016e12cb8b8404aa75c5312236fbcd78@microsoft.com"},"message":"Make Platforms/Targets pkgs work w/packages.config\n\nMicrosoft.NETCore.Platforms and Microsoft.NETCore.Targets both contain\nno dependencies or convention-based assets.  They only contain\nruntime.json's.  This is understood by NuGet3+project.json but not\npackages.config (NuGet 3 or 2).\n\nTo permit these packages to install add a placeholder.","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/a9df42d5aaf9de880b52d48a717dcdeecde452c5"},{"sha":"6b0b2c26d16fcdd8347cbc411b859e108247b8d7","author":{"name":"Ian Hays","email":"a9a31768c79309476a28b72906f7b216ea88fd9b@microsoft.com"},"message":"Implement Console support for netcore50\n\nThe Windows implementation currently used for netcore50 will fail the WACK check as it calls a number of APIs unsupported by UWP. This commit adds a separate netcore50 build that stubs out the API calls and replaces them with PlatformNotSupportedExceptions or no-ops where appropriate. The result is a platform-agnostic version of System.Console that can be used anywhere but is severely stripped of functionality.\n\n- Where possible the behavior of a redirected Console operation will attempt to mimic that of a Unix redirected Console operation. Otherwise it will throw.\n- Encoding is fixed to UTF8. Attempting to set the Console encoding will no-op.\n- Added a section in the packaging build for the new netcore50 specific binary\n- Input/Output redirection and subsequent reads/writes work as expected.","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/6b0b2c26d16fcdd8347cbc411b859e108247b8d7"},{"sha":"6d6f5bf35a567dfb0cb5c0554b608693a9f76a54","author":{"name":"Matt Ellis","email":"d7a9f5a11a3bde32d16b3a23c24225c3538df6bd@microsoft.com"},"message":"Merge pull request #8904 from ellismg/enable-other-distros-for-building\n\nEnable other distros for building","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/6d6f5bf35a567dfb0cb5c0554b608693a9f76a54"},{"sha":"da5ac20015484e78c985d973cd51e48767aea627","author":{"name":"Stephen Toub","email":"b60ab4ec0ae5032e51dd285ac67105c722f075d3@microsoft.com"},"message":"Merge pull request #8914 from stephentoub/remove_valuetask_cast\n\nRemove implicit casts from ValueTask<T>","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/da5ac20015484e78c985d973cd51e48767aea627"},{"sha":"04078f074a50988bc63049634c185089b6f41273","author":{"name":"Stephen Toub","email":"b60ab4ec0ae5032e51dd285ac67105c722f075d3@microsoft.com"},"message":"Merge pull request #8918 from stephentoub/valuetask_tostring\n\nFix ValueTask<T>.ToString behavior with null results","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/04078f074a50988bc63049634c185089b6f41273"},{"sha":"0ab0276a0affb6322754353ccbe53140cd34599a","author":{"name":"Eric StJohn","email":"5cba59b6016e12cb8b8404aa75c5312236fbcd78@microsoft.com"},"message":"Merge pull request #8929 from ericstj/MS.NETCore.Targets/Platforms-packages.config\n\nMake Platforms/Targets pkgs work w/packages.config","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/0ab0276a0affb6322754353ccbe53140cd34599a"},{"sha":"c6ff87bd4a72c66ccc31c76bee04f7652ff2488f","author":{"name":"Ian Hays","email":"a9a31768c79309476a28b72906f7b216ea88fd9b@microsoft.com"},"message":"Merge pull request #8853 from ianhays/winrt_console\n\nImplement Console support for netcore50","distinct":false,"url":"https://api.github.com/repos/weshaggard/corefx/commits/c6ff87bd4a72c66ccc31c76bee04f7652ff2488f"},{"sha":"61f3e68eaafb50676fa0f1332fef8d439f07a671","author":{"name":"Eric St. John","email":"5cba59b6016e12cb8b8404aa75c5312236fbcd78@microsoft.com"},"message":"Switch test-runtime to NETStandard.Library\n\nMicrosoft.NETCore.Console soon won't be built with the same versioning\nas the rest of CoreFx: https://github.com/dotnet/core-setup/pull/14\n\nWe don't want to have to \"know\" which version of this package is\nconsistent with the CoreFx version we're picking up.\n\nIn addition to this Microsoft.NETCore.Console was too large: we really\nonly need the test-runtime to bring in a closure of dependencies for the\ntest runner and libraries.\n\nIn addition to this I've split up the validation rules for packages that\nwill soon start coming from other repos.\n\nAdd missing impl dependencies to tests\n\nThese dependencies are exclusive to the product assembly brought in via\nproject-reference.  Because our current restore process doesn't catch\ntransitive package dependencies these need to be added manually.\n\nFix up some of more project dependencies","distinct":true,"url":"https://api.github.com/repos/weshaggard/corefx/commits/61f3e68eaafb50676fa0f1332fef8d439f07a671"},{"sha":"62dd11f230412da275cf7250e22c7b3074f30512","author":{"name":"Wes Haggard","email":"5e205604fa9f467a1cebb57199533008d29f881b@microsoft.com"},"message":"[WIP] Test new CoreCLR package builds.","distinct":true,"url":"https://api.github.com/repos/weshaggard/corefx/commits/62dd11f230412da275cf7250e22c7b3074f30512"},{"sha":"f82d84eb2e2f261bdf765aa87f83c16ff99ae7d3","author":{"name":"Wes Haggard","email":"5e205604fa9f467a1cebb57199533008d29f881b@microsoft.com"},"message":"mend","distinct":true,"url":"https://api.github.com/repos/weshaggard/corefx/commits/f82d84eb2e2f261bdf765aa87f83c16ff99ae7d3"}]}
{"actor":{"display_login":"weshaggard"}}