[2019-06] Bump msbuild to track mono-2019-10 #27
Closed
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
Prompted by mono/msbuild#123 : This includes: Update to upstream vs16.3 branch SDK update to track dotnet release/3.0.100-preview8 Roslyn updated to 3.3.0-beta2-19381-14 * Work around remoting1.exe test issue with new Roslyn
…spans in m… (mono#16123) * [System] Guard against attempting to creating out-of-range spans in macOS FileSystemWatcher Backport of mono#16049
…elements. (mono#16108) * Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements. mono#16010 The current behavior for GetConstructorCandidates when the name is null, "", or "*" is to return the set of constructors for the type. For "", .NET Core and .NET Framework return 0 elements. This PR adds a check for "" to match that behavior. * Removed unncessary changes * Unnecessary spaces * Made the if check a bit more readable
This will allow the interpreter to use System.Reflection.Emit. Note: There is a small size increase (about 50kb) for an application built in release mode with the LLVM backend (even if the interpreter is now used). Backport of mono#16151
(cherry picked from commit b60aaea)
The loop body uses coop handles, so wrap it in HANDLE_FUNCTION_ENTER/HANDLE_FUNCTION_RETURN Addresses part of mono#16179 Backport of mono#16184.
Fixes mono#16032 When we switched to corefx File.Copy on unix, the behavior changed where it opened a source and destination stream in order to pass the safe handles to Interop.Sys.CopyFile. This exposed a flaw in our sharing validation rules in MonoIO.Open, which threw an exception in this scenario: new FileStream("source.txt", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.ReadWrite, 2048, FileOptions.DeleteOnClose); new FileStream("source.txt", FileMode.Open, FileAccess.Read, FileShare.Read, 2048, FileOptions.None); Simplified the FileShare check down to: 1. If the caller specifies FileShare.None, then it's an exclusive lock and no sharing is allowed. 2. If the caller specifies some other FileShare option, then FileShare.None cannot be specified.
…ateStream()`. (mono#16327) * Add missing `Dispose()` call on error in `MonoTlsStream.CreateStream()`. * Remove the `finally` block to make it more easy to read. Backport of mono#16233.
…ono#16392) The intention of calling `g_file_test (file, G_FILE_TEST_EXISTS)` where file is the name of a shared library we want to open is to speed up probing for non-existent libraries. See mono#12074 The problem is that if file is just a simple "libdl.so" then `dlopen (file)` doesn't just look for it in the current working directory, it will probe some other paths too. (For example on desktop linux you'd also look in all the directories in LD_LIBRARY_PATH). So the g_file_test() call is not a robust way to avoid calling dlopen if the filename is relative. But it actually broke more things: dotnet/android#3388 When probing for "libdl.so" on Android mono_lookup_pinvoke_call will first try prepending some paths that it knows about and we end up calling `dlopen ("/system/lib/libdl.so")` which will fail because Bionic has security restrictions on what code can dlopen something from /system/lib with an absolute path. Eventually mono_lookup_pinvoke_call will go back to trying the bare "libdl.so" which hits `g_file_test` and returns NULL. The new code only does the file test if we pass it an absolute path, which gives Bionic's dlopen a chance to deal with relative paths however it needs to.
Currently, if the process is 32-bit, roslyn tries to determine how much memory is available. To do that, it tries to pinvoke into GlobalMemoryStatusEx, which is not supported on mono. Without it, the compiler server bombs on https://github.com/dotnet/roslyn/blob/0e63260c5afb3fb5b74c357dd250e500172bcd63/src/Compilers/Server/VBCSCompiler/NamedPipeClientConnection.cs#L55-L5 Backport of mono#16405
…#16034. (mono#16424) Using the CoreCLR version of this line fixed the problem and my investigations also revealed why. The `SafePipeHandle` contains a reference to both the Socket as well as the `SafeSocketHandle`, taking ownership of them. If there are no additional references to either of them, so that both are collected in the same GC pass, their finalizer may be invoked in any order. If the Socket gets finalized first, it's `SafeSocketHandle` will have a `_mstate` of 8 (two references) at the beginning of `DangerousReleaseInternal()` - which will set it to 6 (one reference plus disposed flag). Then when the `SafePipeHandle` gets collected, it will call `DangerousRelease ()` on it's `SafeSocketHandle`. As mentioned above, it's `_mstate` will be 6. Now we own the handle, so we'll decrease it's reference count by one and set the `Closed` flag - the new `_mstate` should thus be 3. However, using new_state = (old_state & RefCount_Mask) - RefCount_One; would set it to 1 - thus effectively clearing the `Disposed' flag. And since it's reference count is now also zero, the next finalize pass will then throw. The CoreCLR version of this class uses new_state = old_state - RefCount_One; which fixes this. Backport of mono#16244.
* Bump msbuild to track mono-2019-06 .. to get changes from mono/msbuild#130 which tracks dotnet `release/3.0.100-preview9`. Also, bump Roslyn to 3.3.1-beta3-19421-04 . * Bump the roslyn reference
…ble shared compilation again (mono#16445) * [2019-06] bump msbuild to stop disabling shared compilation * Pull in nuget update for preview 9
…e 11 beta6 (mono#16481) As of XCode 11 beta6 the MacOSX SDK defines the MAP_32BIT symbol. This causes the `mono_valloc()` function to try to use the `MAP_32BIT` flag for `mmap()`. However as mentioned in the comment for the symbol in mman.h it seems to require a special entitlement which isn't available/documented anywhere yet. This in turn causes the mmap call to fail presumably because we're missing that entitlement. Instead we now skip setting this flag on Apple platforms to make `mmap()` behave like it did before. Backport of mono#16441
…cisely. (mono#16489) * [w32socket] Translate some errno codes to WSA_ errors imprecisely. These aren't a perfect match, but better than falling into the `default` case where Mono asserts and crashes. Addresses part of mono#16024 * [w32error] Add WSA_INVALID_PARAMETER and WSA_INVALID_HANDLE Backport of mono#16331.
…t feed (cherry picked from commit 8d42243)
…ss is set Fixes https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582 Bumps the HttpClient part in mono/corefx at: mono/corefx@ee3acec The test that would have caught this failure was disabled previously via: mono@2f41175 (cherry picked from commit 580defd)
Resolves mono#16122 Since we put in the corefx version of GZipStream, it is expected that our version of DeflateStream actually implements Write+ReadAsyncMemory. This change does that by just calling the plain WriteAsync & ReadAsync methods until we decide (or not) to pull in the corefx DeflateStream. Backport of mono#16523.
* Use the right FileSystemWatcher sources The corefx code for FileSystemEventArgs has some changes to support constructing one with a null filename. Fixes mono#16486 * Remove the mono sources for the newly replaced files * [csproj] Update project files
…uartz-engine.py (mono#16548) See mono/bockbuild#116 (cherry picked from commit 309cf1b) # Conflicts: # external/bockbuild
…d5. (mono#16575) * Bump ikvm to pick up caa8e7f54279a47422626005d228447f5d3670d5. * [monodis] Add a missing cattr parent case. Backport of mono#16567.
* Revert "[aot] partial revert of mono#14043 (mono#14135)" This reverts commit 223e0bd. * Revert "[aot] change method table generation so that it works for larger assemblies on ARM (mono#14043)" This reverts commit 9ff3b0d.
… dotnet 3.0.100-p9 toolset
Add RenamedEvent* to FSW sources from CoreFX Fixes mono#16486 - This was only partially fixed until now * [csproj] Update project files * Add test files which test these code paths on corefx
Backport of mono#16774
…o#16851) Callers of mono_reflection_create_custom_attr_data_args_noalloc were leaking some of the returned information. Accessed attributes are FixedBufferAttribute and UnmanagedFunctionPointerAttribute.
…r Xamarin.iOS. Fixes xamarin/xamarin-macios#7005. (mono#16896) This is the equivalent of xamarin/xamarin-macios@a9abc07, just for the Mono.frameworks in the mono archive. Fixes xamarin/xamarin-macios#7005.
We sometimes saw the following build error in Mono SDKs builds on Jenkins: ``` [2019-09-16T01:03:30.709Z] CSC [xammac] nunit-lite-console.exe [2019-09-16T01:03:30.709Z] error CS0009: Metadata file '/Users/builder/jenkins/workspace/archive-mono/2019-08/mac/release/mcs/class/lib/xammac/nunitlite.dll' could not be opened -- PE image doesn't contain managed metadata. ``` Taking a closer look we found out that nunit-lite was trying to be built twice for the same profile which caused a race where the file was corrupted. The reason for this is that the corlib Makefile defines two test assemblies: the normal PROFILE_corlib_test.dll and BinarySerializationOverVersionsTest.dll and integrating the BinarySerializationOverVersionsTest.dll via the `test-vts` target incorrectly overwrote the `test` target instead of using `test-local`. Backport of mono#16894.
* [2019-06] Bump msbuild and sdk versions to 3.0.1xx latest * Bump msbuild again to pull in the build updates * pull in roslyn-binaries fix * One more bump * Fix the roslyn hash * [msbuild] Bump to pick up a build fix from mono/msbuild#138 * Pull in final update from msbuild of nuget and sdk NuGet 5.3.0-rtm.6251 Sdk 3.0.100-rc2.19467.3 * Pick up packaging fix in mono/msbuild#141
…mono#16933) Because the system location isn't world writeable on Catalina.
This was requested by the xamarin-macios team. (cherry picked from commit 6ad929c)
Requested by xamarin-macios team. (cherry picked from commit 0a3c9c4)
Xamarin.Mac doesn't need nor use it anymore. This also removes the last part of the mono archive that required Xcode 9.4.
…) (mono#16851)" This reverts commit a6b5187.
There is an issue with jumping into DST for some time zones when the incorrect date-time offset is returned for date-time in UTC (which comes from DateTime.Now). The fix is to just check if the incoming date-time is in UTC Also I added set of tests for some time zones but they verify jumping into DST in general. Fixes mono#16395 Backport of mono#16430
Contributes to mono#17064
…r catch generated by the method called in the owner thread, so we don't need to throw as unhandled exception, we can continue and find the next catch. Fixes mono#17083 Backport of mono#17106.
* [2019-06] Add drawing type converters to mobile profiles Needed for dotnet/android#3726 * Bump API snapshot submodule * [csproj] Update project files
* Bump corefx to get Azure testhost change See mono/corefx#360 * Update ClientWebSocketTest as well (cherry picked from commit d457346) # Conflicts: # external/corefx
…etry (mono#17296) * [merp] Put thread into async context before running summarizer [merp] Put thread into async context before running summarizer Followup work for mono#17090 In order to get managed method info for unmanaged stacktraces, we call `mini_jit_info_table_find_ext` which calls `decode_exception_debug_info` which may allocate if it's not in async context. Do the switch in `mono_threads_summarize_execute` so that non-supervising threads all switch when they run the `sigterm_signal_handler`. `mono_threads_summarize` already does it for the supervisor thread. Fixes mono#17180 Backport of mono#17194. /cc @lambdageek * [merp] Don't call install_state_summarizer in EnableMicrosoftTelemetry install_state_summarizer installs a SIGTERM handler. Unfortunately sigterm_signal_handler assumes that it will only be called when a crash is already in progress (it assumes it won't be the supervisor, and so it doesn't setup the memory for capturing a crash report among other things). * [merp] Register SIGTERM handler in dump_native_stacktrace Previously it was installed by EnableMicrosoftTelemetry, which is too early. Now we get here without a handler installed even when mono_merp_enabled returns true.
This brings us in line with GetDiskFreeSpaceExW on Windows as well as .NET Core.
radical
pushed a commit
that referenced
this pull request
Jan 10, 2020
[2019-12] [debugger] skip suspend for unattached threads When the debugger tries to suspend all the VM threads, it can happen with cooperative-suspend that it tries to suspend a thread that has previously been attached, but then did a "light" detach (that only unsets the domain). With the domain set to `NULL`, looking up a JitInfo for a given `ip` will result into a crash, but it isn't even necessarily needed for the purpose of suspending a thread. More details: Consider the following: ``` (lldb) c error: Process is running. Use 'process interrupt' to pause execution. Process 12832 stopped * thread #9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1 frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6 2713 MonoDomain *domain = (MonoDomain *) mono_thread_info_get_suspend_state (info)->unwind_data [MONO_UNWIND_DATA_DOMAIN]; 2714 if (!domain) { 2715 /* not attached */ -> 2716 ji = NULL; 2717 } else { 2718 ji = mono_jit_info_table_find_internal ( domain, MONO_CONTEXT_GET_IP (&mono_thread_info_get_suspend_state (info)->ctx), TRUE, TRUE); 2719 } Target 0: (WatchWCSessionAppWatchOSExtension) stopped. (lldb) bt * thread #9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1 * frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6 frame #1: 0x004e177b WatchWCSessionAppWatchOSExtension`mono_thread_info_safe_suspend_and_run(id=0xb0767000, interrupt_kernel=0, callback=(WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical at debugger-agent.c:2708), user_data=0xb04dc718) at mono-threads.c:1358:19 frame #2: 0x00222799 WatchWCSessionAppWatchOSExtension`notify_thread(key=0x03994508, value=0x81378c00, user_data=0x00000000) at debugger-agent.c:2747:2 frame #3: 0x00355bd8 WatchWCSessionAppWatchOSExtension`mono_g_hash_table_foreach(hash=0x8007b4e0, func=(WatchWCSessionAppWatchOSExtension`notify_thread at debugger-agent.c:2733), user_data=0x00000000) at mono-hash.c:310:4 frame #4: 0x0021e955 WatchWCSessionAppWatchOSExtension`suspend_vm at debugger-agent.c:2844:3 frame #5: 0x00225ff0 WatchWCSessionAppWatchOSExtension`process_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0, il_offset=0, ctx=0x00000000, events=0x805b28e0, suspend_policy=2) at debugger-agent.c:4012:3 frame #6: 0x00227c7c WatchWCSessionAppWatchOSExtension`process_profiler_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0) at debugger-agent.c:4072:2 frame #7: 0x0021b174 WatchWCSessionAppWatchOSExtension`thread_startup(prof=0x00000000, tid=2957889536) at debugger-agent.c:4149:2 frame #8: 0x0037912d WatchWCSessionAppWatchOSExtension`mono_profiler_raise_thread_started(tid=2957889536) at profiler-events.h:103:1 frame #9: 0x003d53da WatchWCSessionAppWatchOSExtension`fire_attach_profiler_events(tid=0xb04dd000) at threads.c:1120:2 frame #10: 0x003d4d83 WatchWCSessionAppWatchOSExtension`mono_thread_attach(domain=0x801750a0) at threads.c:1547:2 frame #11: 0x003df1a1 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop_internal(domain=0x801750a0, cookie=0xb04dcc0c, stackdata=0xb04dcba8) at threads.c:6008:3 frame #12: 0x003df287 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop(domain=0x00000000, dummy=0xb04dcc0c) at threads.c:6045:9 frame #13: 0x005034b8 WatchWCSessionAppWatchOSExtension`::xamarin_switch_gchandle(self=0x80762c20, to_weak=false) at runtime.m:1805:2 frame #14: 0x005065c1 WatchWCSessionAppWatchOSExtension`::xamarin_retain_trampoline(self=0x80762c20, sel="retain") at trampolines.m:693:2 frame #15: 0x657ea520 libobjc.A.dylib`objc_retain + 64 frame #16: 0x4b4d9caa WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke + 279 frame #17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12 frame #18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88 frame #19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27 frame #20: 0x453c6ebd Foundation`-[NSOperation start] + 835 frame #21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27 frame #22: 0x453cb12e Foundation`__NSOQSchedule_f + 194 frame #23: 0x453cb26e Foundation`____addOperations_block_invoke_4 + 20 frame #24: 0x65de007b libdispatch.dylib`_dispatch_call_block_and_release + 15 frame #25: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14 frame #26: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421 frame #27: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818 frame #28: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354 frame #29: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109 frame #30: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208 frame #31: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36 ``` Going further, `info` is about this thread: ``` (lldb) p/x *(int *)(((char *) info->node.key) + 0xa0) (int) $2 = 0x01243f93 (lldb) thread list Process 12832 stopped thread #1: tid = 0x1243ee1, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_303', queue = 'com.apple.main-thread' thread #2: tid = 0x1243ee6, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10 thread #3: tid = 0x1243ee7, 0x65f81aea libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker' thread #4: tid = 0x1243ee9, 0x65f7e3d2 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer' thread #5: tid = 0x1243eea, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10, name = 'Debugger agent' thread #6: tid = 0x1243f1d, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.uikit.eventfetch-thread' thread #8: tid = 0x1243f93, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)' * thread #9: tid = 0x12443a9, 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1 thread #10: tid = 0x1244581, 0x65f7fd32 libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) thread select 8 * thread #8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)' frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10 libsystem_kernel.dylib`mach_msg_trap: -> 0x65f7e396 <+10>: retl 0x65f7e397 <+11>: nop libsystem_kernel.dylib`mach_msg_overwrite_trap: 0x65f7e398 <+0>: movl $0xffffffe0, %eax ; imm = 0xFFFFFFE0 0x65f7e39d <+5>: calll 0x65f85f44 ; _sysenter_trap (lldb) bt * thread #8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)' * frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10 frame #1: 0x65f7e8ff libsystem_kernel.dylib`mach_msg + 47 frame #2: 0x66079679 libxpc.dylib`_xpc_send_serializer + 104 frame #3: 0x660794da libxpc.dylib`_xpc_pipe_simpleroutine + 80 frame #4: 0x66079852 libxpc.dylib`xpc_pipe_simpleroutine + 43 frame #5: 0x66043a8f libsystem_trace.dylib`___os_activity_stream_reflect_block_invoke_2 + 30 frame #6: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14 frame #7: 0x65de3d71 libdispatch.dylib`_dispatch_block_invoke_direct + 257 frame #8: 0x65de3c62 libdispatch.dylib`dispatch_block_perform + 112 frame #9: 0x6604349a libsystem_trace.dylib`_os_activity_stream_reflect + 725 frame #10: 0x6604ef19 libsystem_trace.dylib`_os_log_impl_stream + 468 frame #11: 0x6604e44d libsystem_trace.dylib`_os_log_impl_flatten_and_send + 6410 frame #12: 0x6604cb3b libsystem_trace.dylib`_os_log + 137 frame #13: 0x6604f4aa libsystem_trace.dylib`_os_log_impl + 31 frame #14: 0x4b4eb4e9 WatchConnectivity`WCSerializePayloadDictionary + 393 frame #15: 0x4b4d7c4d WatchConnectivity`-[WCSession onqueue_sendResponseDictionary:identifier:] + 195 frame #16: 0x4b4da435 WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke.411 + 35 frame #17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12 frame #18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88 frame #19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27 frame #20: 0x453c6ebd Foundation`-[NSOperation start] + 835 frame #21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27 frame #22: 0x453cb12e Foundation`__NSOQSchedule_f + 194 frame #23: 0x453cb067 Foundation`____addOperations_block_invoke_2 + 20 frame #24: 0x65dedf49 libdispatch.dylib`_dispatch_block_async_invoke2 + 77 frame #25: 0x65de4461 libdispatch.dylib`_dispatch_block_async_invoke_and_release + 17 frame #26: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14 frame #27: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421 frame #28: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818 frame #29: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354 frame #30: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109 frame #31: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208 frame mono#32: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36 ``` which is a thread in a "light" detach state (aka. coop detach), where we only unset the domain: https://github.com/mono/mono/blob/4cefdcb7ce2d939ee78fb45d1b4913eb3bc064fd/mono/metadata/threads.c#L6084-L6111 Fixes mono#17926 <!-- Thank you for your Pull Request! If you are new to contributing to Mono, please try to do your best at conforming to our coding guidelines http://www.mono-project.com/community/contributing/coding-guidelines/ but don't worry if you get something wrong. One of the project members will help you to get things landed. Does your pull request fix any of the existing issues? Please use the following format: Fixes #issue-number --> Backport of mono#18105. /cc @lewurm
radical
deleted the
bump_msbuild_2019-06_644d2d40-2d59-471e-9df9-a76738ecb5f2
branch
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.
No description provided.