Skip to content

Conversation

pull[bot]
Copy link

@pull pull bot commented Feb 14, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

DanielEScherzer and others added 19 commits February 14, 2025 11:47
Second pass through `Zend/tests/bug*` to organize the tests.

Move tests to existing sub directories, and create some new sub directories:
* `ArrayAccess`
* `autoload`
* `clone`
* `serialize` (also covers `unserialize()`)
* `switch`

Work towards GH-15631
gcc gave up on the initial patchset for `element_count` and went
by `counted_by` since last october.
* PHP-8.4:
  Fix curl protocols test expectation
When the `zend_class_entry` has a `zend_function` entry for `clone`, the logic
is the same regardless of if the `reflection_object` entry has an object or
not; the determination is based solely on the flags of the `zend_function`.
- Removed unused variable  from getHeaders function.
- Simplified regex by removing unnecessary lazy quantifiers ().
- Removed unnecessary  flag from regex patterns.
This improves readability and reduces redundant code without altering functionality.
It seems like n === undefined must have worked on older versions of
jscript, but currently it just causes the insertion to silently fail.
This sets n to an empty string, allowing phpize to include the local
config.w32 files.
* PHP-8.1:
  [skip ci] Fix phpize for Windows 11 (24H2)
* PHP-8.2:
  [skip ci] Fix phpize for Windows 11 (24H2)
* PHP-8.3:
  [skip ci] Fix phpize for Windows 11 (24H2)
* PHP-8.4:
  [skip ci] Fix phpize for Windows 11 (24H2)
The 32bit implementation seems to be okay, but we rather should avoid
falling back to the double (pun intended) calculation for non `__GNUC__`
systems.  We use the intsafe.h intrinsics instead for MSVC and
compatible compilers.
C4018[1] is about unsigned/signed comparisons; C4267[2] is about
conversion from `size_t` to a "smaller" type.  We likely should resolve
these warnings in the long run, but for now, it seems like a no brainer
to elevate to `/W3` even if we have to exempt two additional categories
of warnings, since we can catch some others.  And we no longer need to
elevate C4010[3] to a higher level to catch it.

[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4018>
[2] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4267>
[3] <https://learn.microsoft.com/de-de/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4013>
The `$module_name` of `com::__construct()` can be a ProgID, ClassID or
moniker.  We first try `CLSIDFromString()`, and if that fails, we go
ahead and try to treat the `$module_name` as a moniker.  If that also
fails, we throw an exception with the result of `MkParseDisplayName()`
what would just be `MK_E_SYNTAX` if given a ProgID.  This result is
highly confusing for the common case where a ProgID is given, which is
not registered (e.g. due to a typo).  In this case, we use the original
`HRESULT` (`CO_E_CLASSSTRING`) instead.
@pull pull bot added the ⤵️ pull label Feb 14, 2025
@pull pull bot merged commit 252b52a into wudi:master Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants