Repository navigation
Conversation
This would simplify greatly puppetization of Zend modules such as xdebug in heterogeneous environments. For example: zend_extension="/usr/lib/php5/20090626/xdebug.so" can become: zend_extension=xdebug.so
|
Looks like a false positive. I pulled again just in case and git 1.7.11.4 rebased like a charm. |
|
BTW, I didn't look into your branching model (not a PHP fan, sorry), but a backport of this feature in 5.3 (which I developed this for) and 5.4 would be most welcome. Any chance that might happen? Is there a procedure I can follow for that? |
There was a problem hiding this comment.
It's not a good idea make Zend engine rely on php
There was a problem hiding this comment.
php.h is used for DEFAULT_SLASH, IS_SLASH and INI_STR("extension_dir").
Do we have equivalents in the Zend world?
There was a problem hiding this comment.
that is one reason of why zend extension does not support relative path.
There was a problem hiding this comment.
OK. Could we consider an optional approach based on dlsym?
There was a problem hiding this comment.
yes, including php.h in Zend Engine files is definitely a no go. Same for using any symbols not originating in Zend Engine.
|
Hi, @travisbot is a bot indeed , and PHP's test on travis-ci.org didn't works that well. you could ignore that for now:) |
|
Comment on behalf of laruence at php.net: won't fix, it's trivial and fixing this will need over expensive costs |
|
EDIT: Found reasonable fix after posting. A little hacky, but it works. Still think this is a reasonable request, but not a blocker :) Not so trivial for config management tools as they are put in developer's hands. Hitting the same issue with chef. Throws a big red error that is confusing to new users on the first boot of any environment that is provisioning. System's integration tools are getting simpler and simpler to pass to developers, so I can't imagine my project will be the only one it affects. Anyone using xdebug with vagrant (and any config management tool that rightfully passes warnings forward) should see it flash up on the first boot |
|
https://bugs.php.net/bug.php?id=54564 |
Problem Four ways a structure rule went wrong, from php#159's review: - A Lean file a Module.lean imports was no input of any .sharpc. Editing it left every .sharpc current, so the code its new rule refuses kept running until something else changed. An imported Module.lean in a folder with no .sharp file got no generated module, so Lean rejected the Module.lean that imported it with "unknown module prefix". - A Module.lean outside every PSR-4 folder was ignored without an error, so its rules never ran. - A @[rule] in a Lean file that is no Module.lean and that nothing imports was never built, so it was never reported. When a Module.lean imported such a file, the issue named the Module.lean and Lake's "object file ... does not exist", not the file and its error. - The facts code walked use forms, functions, constants and traits that no .sharp file can write, and Facts.lean carried their kinds. Rule.importsOnly also refused the standard library, so the spec's own 28.1 rule refused import Sharp.Json.Json. Solution rules_files takes the workspace root and returns the Module.lean of each folder up to the root plus every workspace Lean file they import, transitively, through the PSR-4 folders of composer.json. The orchestrator gets the list through a new rules closure, as it gets stamps, and rules::find reads the same list. Every Lean file the rules step builds gets an empty generated module when no translation names one. A Module.lean in no PSR-4 folder refuses each .sharp file under its folder: "lib/Shop/Module.lean is in no PSR-4 folder of composer.json, so its structure rules have no Lean module name and cannot run." The rules step also builds every Lean file of a PSR-4 folder that is neither a Module.lean nor a proof file and that no Lean file imports. One Lean rejects refuses each file of its folder's namespace. A rejected file is reported with the first error of the file that holds it: a Module.lean that imports a rejected file names that file and its first error, and an import of a workspace Lean file that no longer exists is named as such, since Lake's stale build output hides it from Lean. The facts code keeps only what a .sharp file declares and imports: class, interface and enum declarations and class-like imports. SymbolKind, Import.kind and the trait, function and constant declaration kinds are deleted in Rust and in Lean. Rule.importsOnly always allows Sharp, the standard library; neverImports still forbids a part of it. crates/sharp-lean/ ├── lean/Sharp/Lean/Facts.lean <- no SymbolKind or Import.kind; DeclarationKind is class, │ interface and enum; importsOnly allows Sharp ├── lean/Sharp/Lean/Runner.lean <- decodes the smaller facts └── src/ ├── rules.rs <- rules_files(root, name) follows imports; LeanFile and Role │ (Module.lean, imported, unreached); first_error names the cause ├── lean.rs <- refuses files under a Module.lean in no PSR-4 folder; │ builds every workspace Lean file the rules step finds ├── facts.rs <- one walk_in_use_item; no trait, function or constant facts ├── runner.rs <- an import fact has no kind byte ├── issues.rs <- rejected_rules_import names the cause's error; │ rejected_lean and no_rules_module added └── package.rs <- linked_roots is shared with rules.rs crates/orchestrator/.../compile.rs <- compile(stamp, rules, check) crates/server/src/server.rs <- Server::compile(stamp, rules, check) src/commands/compile.rs <- passes rules_files with the workspace root tests/compile.rs <- rows for each review finding; the import-order test is replaced by the incremental rows tests/server_engine.rs <- passes an empty rules list tests/external_analyzer_refinement.rs <- passes an empty rules list Completes: none (section 28 completes with PR 5)
feat: check structure rules in mago compile
Problem: Master gained php#157 (`: super(…)` constructor initializers) and php#159 (structure rules), and a PR must be up to date with master to merge. Solution: Merge master. Two files conflicted only where both sides added imports or a method beside each other, and both are kept. The constructor initializer's static call passes no type arguments to the generics slice's `analyze_static_method_call`. One generics test's `OrderBox` constructor now calls `: super(item)`, which php#157 requires, and drops an `out` marker that the slice refuses. crates/analyzer/src/statement/function_like/mod.rs <- both import sets crates/sharp-bridge/src/lower/types.rs <- method_metadata and parent_constructor both kept crates/analyzer/src/statement/class_like/method.rs <- `: super(…)` passes no type arguments crates/analyzer/tests/sharp.rs <- OrderBox calls `: super(item)`
8 participants
This would simplify greatly puppetization of Zend modules such as xdebug
in heterogeneous environments.
For example:
zend_extension="/usr/lib/php5/20090626/xdebug.so"
can become:
zend_extension=xdebug.so