Repository navigation
Conversation
|
Comment on behalf of stas at php.net: merged |
heyJordanParker
added a commit
to heyJordanParker/php-sharp
that referenced
this pull request
Oct 13, 2026
Problem: tests/sharp_messages.rs read test sources to demand a .php twin beside each .sharp message test. Most twins it forced asserted that a .php file reports nothing for a rule the PHP# gate already keeps out of .php files, so they proved no spec rule and failed on no real bug. Others pinned upstream text the .sharp rule never touches. Fifteen twins pinned an upstream Mago miss as correct: PHP refuses the file and Mago reports nothing. Four .sharp messages still pointed at fixes PHP# does not have: "or not imported", a help without the PHP# call forms, a type message named after PHP's kinds, and `as` for an `Any?`, which leaves it nullable. Solution: tests/sharp_messages.rs and the root package's proc-macro2, syn and regex dev-dependencies are deleted. A .php twin stays only where the .sharp rule changes code .php also runs, such as a display function with a dialect branch or a check that splits on `is_sharp()`, and it asserts only that shared path's messages, filtered as `stepping_or_ordering_an_any_names_it_any` filters. Each upstream miss is an after-v1 issue, php#133 to php#147, that names the PHP error, the code and the test. The four .sharp messages are reworded, and the comparison and spaceship helps move with the `Any?` help. Each .php message stays byte for byte. The sharp-bridge tests run the same banned-word check on every issue they check. Cargo.toml <- root dev-dependencies proc-macro2, syn, regex deleted Cargo.lock <- their edges deleted; regex edge added to mago-sharp-bridge tests/sharp_messages.rs <- deleted crates/analyzer/ ├── src/expression/ │ ├── binary/arithmetic.rs <- `Any?` operand help: check with `is` or `match` │ ├── binary/comparison.rs <- `Any?` comparison help: check with `is` or `match` │ ├── binary/spaceship.rs <- `Any?` `<=>` help: check with `is` or `match` │ ├── unary.rs <- `Any?` negate, increment, decrement help: `is` or `match` │ ├── call/mod.rs <- missing function help: spelling, `this.f()`, `Class.f()`, a `.php` file │ └── constant_access.rs <- missing constant: no "or not imported"; help names PHP# constants ├── src/statement/function_like/mod.rs <- "Cannot find type `Missing`." └── tests/sharp.rs <- [] twins deleted; kept twins filtered to the shared message crates/semantics/tests/sharp.rs <- [] twins deleted; kept twins filtered to the shared message crates/sharp-bridge/ ├── Cargo.toml <- regex dev-dependency └── tests/common/mod.rs <- checked_file fails on a .sharp issue that names a PHP-only word
This file contains hidden or 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
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.
The documentation for var_export state that it does not handle circular references. However, var_export does not catch recursion. It leaves it to the zend hash functions to catch recursion. In here a E_ERROR is thrown when the recursive limit is hit.
This patch changes the var_export to detect recursion and throw a E_WARNING. E_WARNING was chosen b/c it is documented that var_export does not _handle recursion, but it does not say var_export will cause an E_ERROR. This also allows for user created error handlers to handle the situation.