zlib-ng: avoid suppressing WD4242 and WD4244 #105433

carlossanlop · 2024-07-24T22:44:13Z

I'll propose this change upstream too, I reported the issue and shared my findings here: zlib-ng/zlib-ng#1760

WD4242 and WD4244 are critical compiler warnings that should not be suppressed.

WD4242 would show up in platforms under the /arch/*/ coming from slide_hash_chain.
WD4244 would only show up in Windows when building in Debug configuration and the check_match method is invoked.

check_match gets a proper method definition when the ZLIB_DEBUG property is turned on and resolves to an empty macro that does nothing when ZLIB_DEBUG is turned off.

ZLIB_DEBUG is always turned on by zlib-ng when the Debug configuration is detected. I had initially proposed to add a build option to enable/disable ZLIB_DEBUG manually, but fixing the actual root causes was a better option as suggested.

The invocations of slide_hash_chain are always executed, but need an explicit cast and an preceding assert. There seemed to be a mismatch between the different architectures so I made sure they were all identical.

jkoritzinsky · 2024-07-24T22:46:30Z

Can you add a line to zlib-ng.txt that links to this PR so we can have an accurate description of the changes from upstream?

carlossanlop · 2024-07-24T23:04:32Z

I see 4242 in the CI arm64, coming from slide_hash_neon.c. I was unable to repro locally. I see what the problem is, it will require an separate patch, unrelated to ZLIB_DEBUG.

jkotas · 2024-07-24T23:05:24Z

Are we going to miss any relevant debug-only validation by forcing ZLIB_DEBUG to be OFF?

What would it take to fix the source code of the offending methods instead?

carlossanlop · 2024-07-25T00:33:30Z

Yes, that would make more sense. ZLIB_DEBUG probably doesn't ever need to be manually turned off.

I'll work on that.

src/native/external/zlib-ng/CMakeLists.txt

src/native/external/zlib-ng/deflate_fast.c

src/native/external/zlib-ng/arch/arm/slide_hash_armv6.c

src/native/external/zlib-ng-version.txt

akoeplinger · 2024-07-25T17:01:36Z

The reason why these flags leaked into mono is because zlib-ng.cmake is using add_compile_options() which gets applied to all targets from projects including the file. I fixed that for the old zlib in #91395 and added this comment:

runtime/src/native/external/zlib.cmake

Line 1 in 573461d

    
           # IMPORTANT: do not use add_compile_options(), add_definitions() or similar functions here since it will leak to the including projects

We should fix that in zlib-ng too

src/native/external/zlib-ng.cmake

src/native/external/zlib-ng/deflate_fast.c

carlossanlop · 2024-07-25T17:06:31Z

We should fix that in zlib-ng too

@akoeplinger Is there a way to add compile options that only apply to the fetched content?

akoeplinger · 2024-07-25T17:09:11Z

@carlossanlop you need to do what @jkoritzinsky suggested, use target_compile_options instead

…le_options

…fically for zlib

mtl1979 · 2024-07-25T17:13:08Z

@nmoinvaz @mtl1979 @Dead2 I plan on submitting the zlib-ng changes in this PR to the official zlib-ng repo, once I merge this. Do you agree with them?

I'm not completely sure having asserts in Release build is really necessary... Adding more headers just for one definition is something we really have tried to avoid.

carlossanlop · 2024-07-25T17:18:07Z

I'm not completely sure having asserts in Release build is really necessary... Adding more headers just for one definition is something we really have tried to avoid.

@mtl1979 I noticed that they're used in line 59-60 in slide_hash_sse2.c, hence why I chose to use assert instead of Assert in all my slide_hash* changes.

But if you think we should use Assert instead for my changes in this PR, I can switch. No problem with that.

mtl1979 · 2024-07-25T18:06:40Z

I'm not completely sure having asserts in Release build is really necessary... Adding more headers just for one definition is something we really have tried to avoid.

@mtl1979 I noticed that they're used in line 59-60 in slide_hash_sse2.c, hence why I chose to use assert instead of Assert in all my slide_hash* changes.

But if you think we should use Assert instead for my changes in this PR, I can switch. No problem with that.

I hardly ever work on x86 optimizations... I mostly work on ARM, 32-bit PowerPC and MinGW/MSYS support... When I started with zlib-ng, I was diagnosing ICE in Linaro embedded toolchain for ARMv2. The issue with using normal asserts in Release code is that it introduces branching which will slow down the code... Obviously we don't want unnecessary branching in code that often gets executed. During testing asserts are useful as they can reveal hard-to-find crashes when invalid data is passed to publicly visible functions, but sometimes it will be almost impossible to pass invalid data to some functions as the inputs are either validated or truncated earlier.

carlossanlop · 2024-07-25T23:02:43Z

src/native/external/zlib-ng/deflate_rle.c

+            Assert(s->strstart <= UINT16_MAX, "strstart should fit in uint16_t");
+            Assert(s->match_start <= UINT16_MAX, "match_start should fit in uint16_t");
+            check_match(s, (Pos)s->strstart, (Pos)s->strstart - 1, match_len);


I don't want to restart the CI for this. I can either fix this in a separate PR, or we can just leave it as is:

One assert is not needed

The whole argument could be wrapped in parenthesis to convert the subtraction.

Suggested change

Assert(s->strstart <= UINT16_MAX, "strstart should fit in uint16_t");

Assert(s->match_start <= UINT16_MAX, "match_start should fit in uint16_t");

check_match(s, (Pos)s->strstart, (Pos)s->strstart - 1, match_len);

Assert(s->strstart <= UINT16_MAX, "strstart-1 should fit in uint16_t");

check_match(s, (Pos)s->strstart, (Pos)(s->strstart - 1), match_len);

I'll make sure to submit the upstream PR with this fix though.

carlossanlop · 2024-07-25T23:13:15Z

/ba-g Failure is unrelated #105440 and has already been fixed in main #105445

WD4242 and WD4244 are compiler warnings that should not be suppressed because the warn about possible loss of data. WD4242 shows up in zlib-ng/arch/*/slide_hash*.c files and comes from the arguments passed to the slide_hash_chain method. WD4244 happens in Windows when building in Debug configuration, in various zlib-ng/deflate*.c files, and comes from the arguments passed to the check_match method. Fixed by: - Adding asserts to verify the values are below the maximum allowed for their type. - Casting them the proper type before passing them as arguments to their methods. - Removing the WD suppressions, which unfortunately also propagated to other unrelated cmake files. - Fixed a similar loss of data error in an unrelated mono file where the warning suppression was propagated due to this.

…05110) * Remove support for older LLVM versions, and re-order linker flags We have generally tried to support linking multiple versions of LLVM within our git tree. Every new LLVM version moves symbols around between libraries, and as a result, every new version of LLVM requires different linker flags to build. The command line tool `llvm-config` should tell you the exact flags you need, but it is a problem for us when cross-compiling to rely on this, and as a result, we transcribe the result of various llvm-config outputs directly into Mono's CMakeLists.txt. In an effort to support multiple versions of LLVM, flags common between all supported versions were kept in one place, then the version-specific flags appended afterwards. And this has worked fine for years. However: 1. Whilst we only link with `lld`, it is common for contributors and source-build to link with `gold`, `bfd`, or some other GNU-flavoured linker, where library order is essential 2. The list of common libraries to link has remained unchanged for years, but the symbol intra-dependencies may have changed a long time ago, so common symbol order cannot be assumed to remain valid between LLVM versions This has resulted in a long-standing problem for people using e.g. Debian or Ubuntu or GitHub CodeSpaces, rather than always building with one of our dockerfiles representing our "real" build environment, when targeting platforms which use Mono and link LLVM. * Bumping clang and llvm - make docs less ambiguous. (#105401) * Bump main to RC1 (#105338) * Update SDK to preview 6 (#104696) * Update SDK to preview 6 * Update Shared.csproj Fix `error NU1903: Package 'System.Text.Json' 8.0.0 has a known high severity vulnerability` * Fix with existing version. --------- Co-authored-by: Ilona Tomkowicz <32700855+ilonatommy@users.noreply.github.com> Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com> * Change DefaultMaximumErrorResponseLength to KB from Byte (#105396) * Change DefaultMaximumErrorResponseLength to KB from Byte * Handle overflow * Review feedback * Fix warning for MakeGenericType annotation mismatch (#104921) Fixes warning code when a generic type whose type parameters have DAM annotations is used with MakeGenericType, over a type that doesn't have matching annotations. The code IL2070 used to mention the 'this' argument. Instead it should have been IL2071 which mentions the generic argument as the cause of the mismatch. Similar for MakeGenericMethod with IL2090 and IL2091. * Set GCStressIncompatible on GenericContext tests (#104686) Co-authored-by: Vladimir Sadov <vsadov@microsoft.com> * Add runtime config parameter to force ijwhost to load assemblies in an isolated context (#105337) * Add support for isolated load context in LoadInMemoryAssemblyInContext by passing -1 as loadContext * Have ijwhost check a runtime config parameter to determine if it should run in an isolated load context * Added test for ijwhost isolated load context runtime config option * [RISC-V] Fix passing float and uint arguments in VM (#105021) * Add tests * Fix passing float and uint arguments in VM * Change test lib name so it doesn't clash with managed DLL on Windows * Fix platform analyzer attribute order for MacCatalyst (#105409) We need to make sure the attribute for MacCatalyst comes _after_ the iOS one due to how MacCatalyst is a superset of iOS: https://learn.microsoft.com/en-us/dotnet/standard/analyzers/platform-compat-analyzer#platform-inclusion This caused an error in aspnetcore in the latest dependency flow because the analyzer thought AesGcm is _only_ supported on MacCatalyst: > error CA1416: (NETCORE_ENGINEERING_TELEMETRY=Build) This call site is reachable on all platforms. 'AesGcm.Decrypt(ReadOnlySpan<byte>, ReadOnlySpan<byte>, ReadOnlySpan<byte>, Span<byte>, ReadOnlySpan<byte>)' is only supported on: 'maccatalyst' 13.0 and later. * Use correct `ExceptionArgument` value in `System.IO.Pipelines` (#105418) * Remove zlib from requirements script and instruction files (#105419) * Remove zlib from requirements instructions * Remove zlib from native requirements installation script * Revert "Remove zlib from requirements script and instruction files (#105419)" (#105449) This reverts commit 3ec6286. * Ensure that WaitForPendingFinalizers has seen the expected Full GC count (#105289) * Ensure that WaitForPendingFinalizers has seen the expected Full GC * NativeAOT and some renames * a testcase * make the test not unsafe and make OuterLoop * Use unsigned math when comparing collection ticks * cast the diff to int when comparing gc ticks * Migrate to zlib-ng, part 3: Remove zlib and zlib-intel source code and license mentions (second attempt) (#105371) * Remove zlib/ * Remove zlib-intel/ * Remove third party notice * Remove patches * Remove version txts * Remove cgmanifest.json entries * Remove installer third party notice * Update docs --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com> * [browser] Trigger relink on `EmccMaximumHeapSize` change (#105027) * Edit test + trigger relink. * Remove logging to speed up the test + decrease loop runs to prevent "Browser has been disconnected" error. * Feedback - properties are not bool-only anymore. * Fix: workload needed when heap size set. --------- Co-authored-by: Larry Ewing <lewing@microsoft.com> * Delete erroneous Socket test (#105448) * Pull the python dependency from the EmsdkVersion where possible (#105437) * Use `BinaryPrimitives` more in the ILCompiler (#105404) * JIT: use VNVisitReachingVNs in IsVNNeverNegative (#105197) * Set xunit env var to not print output for passing tests (#105392) * Set xunit env var to not print output for passing tests Fixes #103445 * Update xunit.console.targets * Update xunit.console.targets * Some more automated C# modernization in corelib (#105151) * Fix IDE0056 on corelib (indexing can be simplified) * Fix IDE (null check can be simplified) * Fix IDE0078 (use pattern matching) * Fix IDE0019 (use pattern matching) * Fix IDE0066 (use switch expression) * Fix IDE0250 (struct can be made readonly) * Fix nullability warning and address PR feedback * Address PR feedback and revert a downlevel change * Wrap any `?? throw new`s that go beyond 120 characters * Fix ECMA 355 Partition download links (#105454) On https://github.com/dotnet/runtime/blob/main/docs/project/dotnet-standards.md the Partition with Notes download links using HTTP protocol fail to download in Chrome: >Mixed Content: The site at 'https://github.com/' was loaded over a secure connection, but the file at 'https://download.microsoft.com/download/7/3/3/733AD403-90B2-4064-A81E-01035A7FE13C/MS%20Partition%20I.pdf' was redirected through an insecure connection. This file should be served over HTTPS. See https://blog.chromium.org/2020/02/protecting-users-from-insecure.html for more details. (It might be reasonble for somebody else to followup fixing all domains on all pages with regex `\(http://([.a-z0-9-]+)` replacing with `(https://$1`, but I didn't test each blog site supports HTTPS.) * Add swiftcall signature check for `mono_class_try_get_swift_error_class` (#105408) * Add signature check for swiftcall * Handle null values for swift_error_ptr * Enable NativeAOT runtime tests on MacCatalyst (#102882) This PR updates the CLRTest.Execute.Bash.targets file to set the apple run command for MacCatalyst. The command apple just-run used on Apple mobile is not permitted, and apple test requires the a test runner. Additionally, it is necessary to locate Info.plist in the Contents/ directory and the binary in Contents/MacOS/ within the bundle. --------- Co-authored-by: Ivan Povazan <ivan.povazan@gmail.com> * Resolving an antigen failure (#105260) * Resolving an antigen failure * Fix method accessibility so xunit doesn't complain * Support field access on GetType() of T constrained to be Enum (#105351) Adds trimming support for instance.GetType().GetFields(), where instance is a variable of type `T` that is constrained to System.Enum. This includes a change to have ILLink's TypeProxy track a TypeReference instead of TypeDefinition, which was necessary to allow TypeProxy to represent a generic parameter. Note that this only supports the specific case where `GetType()` is called on a variable of type `T` that is constrained to `Enum`. A variable of type `Enum` is not supported, so the following will still warn: ```csharp static void M(Enum v) { v.GetType().GetFields(); } ``` * Update mono to support shuffle for constant inputs (#105299) * Support mono creating xconst in a few more places * Update mono to support shuffle for constant inputs * Ensure that arm64 also accelerates shuffle for non-constant inputs * Ensure OP_XZERO and OP_XONES are recognized as being constant * Ensure shuffle creates a correct instruction when the fsig doesn't match the necessary parameter count * Ensure that getting the index for floating-point shuffle is possible * Ensure the right class handle is passed down to LLVM so overload resolution can function * Make sure we update the original xconst if we mutate it * Return a new constant and instead of mutating the existing one * Insert relevant xcast nodes * Add some asserts around the ecount * Ensure we get the right element type * Ensure we don't create nodes unnecessarily for create_elementwise * Ensure that create_elementwise still works for other vector sizes * Ensure indentation of switch cases is correct for Mono * Make TooDeepJsonDocument test more consistent across platforms (#105445) * Make TooDeepJsonDocument test more consistent across platforms Run the test on a thread with as consistent a stack size as possible so that we don't inadvertently succeed due to having a really large stack. * Disable test on mono * Update the TypeLib embedding and add comments on API use (#105416) There is an undocumented semantic of Win32 Resource APIs. The missing semantic is that all resource type/name strings are transparently converted to uppercase when calling any of the Win32 Resource APIs. We don't want to apply this undocumented semantic to the reader/writer API so we document it instead. We are avoiding applying the behavior since ReadyToRun scenarios are designed to be a byte for byte copy of the resource, including name as it was written by other tooling. * Update docs for ByRefLike with generics for work in .NET 10 (#103318) Co-authored-by: Jan Kotas <jkotas@microsoft.com> * Fix double printing in StressLog and simplify stresslog macros (#105420) * Add support for nested types in the `corelib.h` parser for rooting descriptors (#105432) * Fixed for assertion failure due to not checking if we are processing Eph samples (#105164) * [PERF] Use correct python executable on windows in venv (#105451) * Fix up Fuzzlyn CI scripts for new hardware intrinsics support (#105470) 1) Strip out the extensions in the seed name when using it for file/directory names, since the list of extensions is quite long 2) Limit the number of unreduced/uncategorized example seeds we show * Try to re-enable DeepEquals_TooDeepJsonDocument_ThrowsInsufficientExecutionStackException test on mono (#105509) * zlib-ng: avoid suppressing WD4242 and WD4244 (#105433) WD4242 and WD4244 are compiler warnings that should not be suppressed because the warn about possible loss of data. WD4242 shows up in zlib-ng/arch/*/slide_hash*.c files and comes from the arguments passed to the slide_hash_chain method. WD4244 happens in Windows when building in Debug configuration, in various zlib-ng/deflate*.c files, and comes from the arguments passed to the check_match method. Fixed by: - Adding asserts to verify the values are below the maximum allowed for their type. - Casting them the proper type before passing them as arguments to their methods. - Removing the WD suppressions, which unfortunately also propagated to other unrelated cmake files. - Fixed a similar loss of data error in an unrelated mono file where the warning suppression was propagated due to this. * Delete outdated comments (#105519) * Arm64/Sve: Add FFR register liveness tracking (#105348) * Add tracking of FFR register somewhat workable code cleanup Remove FFR Add all the GetFfr* wip Work with MskCns() model Use physReg approach Remove commented prototypes working Remove bunch of unnecessary code Remove SpecialImport from GetFFR/SetFFR/LoadFirstFaulting some more code cleanup some fixup * Change condition for PhysReg * jit format * review feedback * unspill for LoadVectorFirstFaulting as well * Use the right opReg * skip spilling tracking * review feedback * Use non-existent REG_FFR * Do not reload from FFR for GetFfr() * review feedback * Make just GrabTemp * fix build and formatting * missed another build failure for arm * Fix throwing exception when calling RunClassConstructor on a generic type with a static constructor (#105513) * Fix throwing exception when calling RunClassConstructor on a generic type with a static constructor #99183 seems to have done away with assuming that a generic type's static constructor was always "initialized". As a result, if you call RunClassConstructor on it, the runtime would throw an exception. Fixes #103891 * Apply suggestions from code review --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com> * [RISC-V][LoongArch64] New passing info for floating-point structs (#103945) * Replace StructFloatFieldInfoFlags with FpStructInRegistersInfo which carries also exact field sizes and offsets * Replace StructFloatFieldInfoFlags with FpStruct::Flags in profiler * Remove FpStructInRegistersInfo::FromOldFlags() * Fix duplicating types in HandleInlineArray * Remove signedness from FpStruct::IntKind because most probably we won't need it * Remove old StructFloatFieldInfoFlags calculating routine * Typo in TARGET_LOONGARCH64 * Remove m_returnedFpFieldOffsets from ArgIterator * Add missing ENREGISTERED_PARAMTYPE_MAXSIZE condition to C# version of FpStruct info calculation * Rename RISCV64PassStructInRegister to match settled casing for RiscV in class names * Update hardcoded flags for float and double in ArgIteratorTemplate::ComputeReturnFlags() This fixes JIT/HardwareIntrinsics/General/Vector* tests. * Fix build on other platforms * Update LoongArch to use FpStructInRegistersInfo * Remove unused old flag masks * LoongArch64 typo Co-authored-by: Qiao Pengcheng <qiaopengcheng@loongson.cn> * Missing FpStruct namespace Co-authored-by: Qiao Pengcheng <qiaopengcheng@loongson.cn> * Missing FpStruct namespace Co-authored-by: Qiao Pengcheng <qiaopengcheng@loongson.cn> * Missing FpStruct namespace Co-authored-by: Qiao Pengcheng <qiaopengcheng@loongson.cn> * Use FpStruct namespace everywhere in JIT * JIT review * Update StructFloatFieldInfoFlags description * Revert to hitherto instruction set order as it's not the point of this PR * Unify get{LoongArch,RiscV}64PassFpStructInRegistersInfo JIT interfaces * Use JIT_TO_EE_TRANSITION instead of _LEAF because MethodTable::GetFpStructInRegistersInfo may throw * Remove FpStruct::IntKind, we should have similar info in ClassLayout in JIT * Change JIT interface to return a struct similar to CORINFO_SWIFT_LOWERING to facilitate code unification in the future * Change JIT to use new Swift-like getFpStructLowering * Cache CORINFO_FPSTRUCT_LOWERING * Update LoongArch classifier to use CORINFO_FPSTRUCT_LOWERING * Update StructFloatInfoFlags doc comment on C# * Move StructFloatFieldInfoFlags and FpStructInRegistersInfo out of the JIT interface * Merge LoongArch and RISC-V AOT calculation of FpStructInRegistersInfo because they were identical. Move it to Common\Internal/Runtime because it's no longer exposed in JIT interface. * Don't zero-initialize CORINFO_FPSTRUCT_LOWERING * Add note for CORINFO_FPSTRUCT_LOWERING::loweredElements type --------- Co-authored-by: Qiao Pengcheng <qiaopengcheng@loongson.cn> * Ensure we don't reuse temps when calling fgMorphArgs on LIR nodes (#105508) * Ensure constant evaluation of shifts on xarch broadcast the operand to the correct size (#105487) * Ensure constant evaluation of shifts on xarch broadcast the operand to the correct size * Ensure we don't try to execute AVX2 code on unsupported platforms * Use ConcurrentDictionary in runtimecounters test (#105520) * Use ConcurrentDictionary in runtimecounters test Fixes #105443 * Fix build break * Fix issue 98506 - Excessive exceptions generated in StackTraceSymbols (#105530) * Fix issue 98506 - Excessive exceptions generated in StackTraceSymbols * Code review feedback * Clean up some usages of LowLevelList<T> (#105407) * Fix ShuffleThunk cache heap (#105480) There was a problem with using heap from the related LoaderAllocator for shuffle thunk cache heap. I have tested it again and it seems that the issue is gone. So I am removing the workaround, making the cache use LoaderAllocator local heap. Close #55697 * [browser] Fix computing destination sub path and publish extension target path in Wasm SDK (#105458) * Bump flags to LLVM 19, not 16 --------- Co-authored-by: Larry Ewing <lewing@microsoft.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com> Co-authored-by: Ilona Tomkowicz <32700855+ilonatommy@users.noreply.github.com> Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com> Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com> Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com> Co-authored-by: Ahmet Ibrahim Aksoy <aaksoy@microsoft.com> Co-authored-by: Sven Boemer <sbomer@gmail.com> Co-authored-by: Steve Pfister <steveisok@users.noreply.github.com> Co-authored-by: Vladimir Sadov <vsadov@microsoft.com> Co-authored-by: Mike Oliphant <oliphant@nostatic.org> Co-authored-by: Tomasz Sowiński <tomeksowi@gmail.com> Co-authored-by: xtqqczze <45661989+xtqqczze@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Stephen Toub <stoub@microsoft.com> Co-authored-by: Paulus Pärssinen <paulus.parssinen@gmail.com> Co-authored-by: Egor Bogatov <egorbo@gmail.com> Co-authored-by: Carl Walsh <darthwalsh@gmail.com> Co-authored-by: Milos Kotlar <kotlarmilos@gmail.com> Co-authored-by: Ivan Povazan <ivan.povazan@gmail.com> Co-authored-by: Tanner Gooding <tagoo@outlook.com> Co-authored-by: Aaron Robinson <arobins@microsoft.com> Co-authored-by: Jeremy Koritzinsky <jekoritz@microsoft.com> Co-authored-by: Mukund Raghav Sharma (Moko) <68247673+mrsharm@users.noreply.github.com> Co-authored-by: Cameron Aavik <99771732+caaavik-msft@users.noreply.github.com> Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com> Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com> Co-authored-by: Qiao Pengcheng <qiaopengcheng@loongson.cn> Co-authored-by: Mike McLaughlin <mikem@microsoft.com> Co-authored-by: Huo Yaoyuan <huoyaoyuan@hotmail.com> Co-authored-by: Jan Vorlicek <janvorli@microsoft.com> Co-authored-by: Marek Fišera <mara@neptuo.com>

carlossanlop added 3 commits July 24, 2024 15:31

Make ZLIB_DEBUG a build option

2453cc7

Turn off ZLIB_DEBUG in our zlib-ng.cmake

a3d4565

Patch for zlib-ng/

9e23740

carlossanlop added the area-Infrastructure label Jul 24, 2024

carlossanlop requested review from jkoritzinsky, GrabYourPitchforks, jkotas, ericstj and hoyosjs July 24, 2024 22:44

carlossanlop self-assigned this Jul 24, 2024

carlossanlop mentioned this pull request Jul 24, 2024

Windows error C4242: 'function': Conversion from 'unsigned int' to 'Pos', possible loss of data zlib-ng/zlib-ng#1760

Closed

carlossanlop mentioned this pull request Jul 24, 2024

Add option to turn off ZLIB_DEBUG zlib-ng/zlib-ng#1761

Closed

Mention the applied patch in zlib-ng-version.txt

9f5e234

carlossanlop changed the title ~~Make ZLIB_DEBUG an option in zlib-ng to avoid suppressing WD4242 and WD4244~~ Make ZLIB_DEBUG an option in zlib-ng to avoid suppressing WD4242 Jul 24, 2024

carlossanlop changed the title ~~Make ZLIB_DEBUG an option in zlib-ng to avoid suppressing WD4242~~ Make ZLIB_DEBUG an option in zlib-ng to avoid suppressing WD4242 and WD4244 Jul 24, 2024

carlossanlop marked this pull request as draft July 24, 2024 23:04

carlossanlop added 5 commits July 24, 2024 17:37

Revert that

f066d48

Add aserts and casts to slide_hash*

e2106cd

Add asserts and casts to check_match

51c39e0

Remove previous patch

f4e5207

Add the other patches

735a61b

carlossanlop force-pushed the ZLIB_DEBUG_OFF branch from 7def707 to 735a61b Compare July 25, 2024 01:46

carlossanlop commented Jul 25, 2024

View reviewed changes

src/native/external/zlib-ng/CMakeLists.txt Outdated Show resolved Hide resolved

extra space

bb4722d

carlossanlop commented Jul 25, 2024

View reviewed changes

src/native/external/zlib-ng/deflate_fast.c Show resolved Hide resolved

carlossanlop commented Jul 25, 2024

View reviewed changes

src/native/external/zlib-ng/arch/arm/slide_hash_armv6.c Show resolved Hide resolved

carlossanlop commented Jul 25, 2024

View reviewed changes

src/native/external/zlib-ng-version.txt Outdated Show resolved Hide resolved

Remove unnecessary comment

41c1b44

akoeplinger approved these changes Jul 25, 2024

View reviewed changes

jkoritzinsky reviewed Jul 25, 2024

View reviewed changes

src/native/external/zlib-ng.cmake Outdated Show resolved Hide resolved

src/native/external/zlib-ng/deflate_fast.c Show resolved Hide resolved

Comment for PR patch

6e7b5b4

carlossanlop added 2 commits July 25, 2024 10:11

Add comment at the top of zlib-ng.cmake to warn about using add_compi…

ec56c25

…le_options

Remove the add_compile_options, only use target_compile_options speci…

2969513

…fically for zlib

carlossanlop added 2 commits July 25, 2024 10:26

Switch to Assert instead of assert

5074685

Remove the assert includes too

d99757e

carlossanlop requested a review from jkoritzinsky July 25, 2024 17:28

jkoritzinsky approved these changes Jul 25, 2024

View reviewed changes

hoyosjs approved these changes Jul 25, 2024

View reviewed changes

This was referenced Jul 25, 2024

[browser][MT] test failure: Tests timed out. Killing driver service #103524

Open

[NativeAOT] Object synchronization method was called from an unsynchronized block of code. #104340

Closed

carlossanlop commented Jul 25, 2024

View reviewed changes

carlossanlop mentioned this pull request Jul 25, 2024

Fix various loss of data warnings zlib-ng/zlib-ng#1762

Merged

carlossanlop merged commit ecdb625 into dotnet:main Jul 25, 2024
158 of 160 checks passed

carlossanlop deleted the ZLIB_DEBUG_OFF branch July 25, 2024 23:16

carlossanlop mentioned this pull request Jul 25, 2024

zlib-ng patch for WD suppresion fixes #105523

Closed

ericstj mentioned this pull request Aug 6, 2024

[External] zlib has suppressed warnings #76095

Closed

github-actions bot locked and limited conversation to collaborators Aug 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

zlib-ng: avoid suppressing WD4242 and WD4244 #105433

zlib-ng: avoid suppressing WD4242 and WD4244 #105433

carlossanlop commented Jul 24, 2024 •

edited

Loading

jkoritzinsky commented Jul 24, 2024

carlossanlop commented Jul 24, 2024

jkotas commented Jul 24, 2024 •

edited

Loading

carlossanlop commented Jul 25, 2024

akoeplinger commented Jul 25, 2024

carlossanlop commented Jul 25, 2024

akoeplinger commented Jul 25, 2024

mtl1979 commented Jul 25, 2024

carlossanlop commented Jul 25, 2024

mtl1979 commented Jul 25, 2024

carlossanlop Jul 25, 2024

carlossanlop commented Jul 25, 2024

zlib-ng: avoid suppressing WD4242 and WD4244 #105433

zlib-ng: avoid suppressing WD4242 and WD4244 #105433

Conversation

carlossanlop commented Jul 24, 2024 • edited Loading

jkoritzinsky commented Jul 24, 2024

carlossanlop commented Jul 24, 2024

jkotas commented Jul 24, 2024 • edited Loading

carlossanlop commented Jul 25, 2024

akoeplinger commented Jul 25, 2024

carlossanlop commented Jul 25, 2024

akoeplinger commented Jul 25, 2024

mtl1979 commented Jul 25, 2024

carlossanlop commented Jul 25, 2024

mtl1979 commented Jul 25, 2024

carlossanlop Jul 25, 2024

Choose a reason for hiding this comment

carlossanlop commented Jul 25, 2024

carlossanlop commented Jul 24, 2024 •

edited

Loading

jkotas commented Jul 24, 2024 •

edited

Loading