TysonAndre
commented
6 years ago Thoughts: FunctionSignatureMap.php takes around 0.04 seconds to parse/load, which shouldn't be noticeable compared to the rest of analysis. Requiring the entire file isn't going to be slow. If you have differences in the way you analyze it, there's two approaches you could take that would still be efficient:
- Maintain your own copy, periodically sync the changes. Lazily create the object instances based on that format
- Maintain a file which is the list of differences (e.g. signatures to remove (should remove all alternates), signatures to replace, signatures to add, and add those at runtime.
On some systems/disks, I'd think loading hundreds of files could be slower than accessing a single larger file.
Phan's sources of information/inferences about internal functions:
- FunctionSignatureMap.php
- Reflection, or internal_stubs
- https://github.com/phan/phan/tree/master/src/Phan/Plugin/Internal (e.g. https://github.com/phan/phan/blob/master/src/Phan/Plugin/Internal/ArrayReturnTypeOverridePlugin.php for working with closures)
- Some older code in a function Analyzer which special cases functions that have multiple signatures, such as
"implode"(Merged into Phan\Plugin\Internal)
A tangential feature: Phan also has https://github.com/phan/phan/tree/master/.phan/internal_stubs (Phan's FunctionSignatureMap isn't an exact substitute for ReflectionFunction/ReflectionMethod - A function can have multiple alternate signatures)
See https://github.com/phan/phan/blob/0.10.4/.phan/config.php#L427-L439 for an example of this.
- if
!extension_loaded('pcntl'), for example, Phan will use the stub file instead of pcntl, pretend that the resulting signatures can be used as ReflectionMethod, ReflectionFunction, class constants, etc., and go on with analyzing the projects.
internal_stubs is potentially useful to know if a function call would be guaranteed to result in a PHP Error (Too many/few arguments, TypeError)
Again, this is tangential, but having something like https://github.com/DefinitelyTyped/DefinitelyTyped (From typescript and node.js) would be useful for analyzing a project.
- internal_stubs are parsed without being evaluated.
- Having internal_stubs be PHP-like files is readable, but it isn't space efficient or CPU efficient. I'd be fine with a compact serialization with relevant information for Reflection substitutes. I went with something readable because there were a limited, small set of files.
- If a type repository could support representing signatures for different minor versions of PHP modules (e.g. xdebug 2.6 vs 2.5), that would be helpful for users
I wonder if it's necessary to combine both the signature map and stub files? The format of the function signature map is expressive enough for 99.5% of all functions and methods, and the remainder can be handled either on a case-by-case basis or by generically-typed stubs.
Also see https://github.com/phan/phan/issues/1438 . It's probably doable to import the signatures for phpstorm, but they're probably going to need a lot of manual fixing (E.g. phpstorm only supports a single signature, phpstorm might document a type as mixed instead of int|false, etc.
Another thought that I had was that a standardized format might be modified to include additional information. (E.g. using the array key of the number 1)
E.g.
-
Extension(e.g.apcu_fetchis provided byapcu, php's own functions are provided by 'core' and various other modules)This would make it easy to swap the default signatures for an extension with a slightly different extension version. (E.g. allow a user to remove all functions that are part of xdebug 2.6 that aren't in xdebug 2.5, replace signatures that are different in 2.5 than in 2.6)
-
HasNoSideEffects(Functions such as strlen, sprintf (to some degree), etc.) (E.g. to warn about<?php sprintf(...); ?>instead of<?= sprintf(...); ?> -
ReturnValueShouldBeUsed(e.g.Redis->get(), etc. -
Template signatures, similar to what was mentioned for psalm. E.g. array_values accepts
array<mixed,T>as the first argument and returnsarray<int,T> -
Various other custom tags (e.g. Is this argument a class name? Is this argument a regular expression?)
-
Maybe add an entry such as
IgnoreNullableReturn/IgnoreFalseableReturnfor signatures that different analyzers would analyze differently. E.g. phan/psalm would reduce false positives in different ways for a handful of signatures (Either by assuming a smaller set of types or larger set of types). OrOptimisticReturnType => 'int'alongside a declared return type ofint|false.
carusogabriel
muglug
lookyman
artspb
ntzm
Continuing on from the discussion on f486280bf7746e20661f3c917f63749915f1be59, where the diff breaks the interface
Concerning a unified format:
Psalm uses three sources of information for builtin function/method lookups:
I wonder if it's necessary to combine both the signature map and stub files? The format of the function signature map is expressive enough for 99.5% of all functions and methods, and the remainder can be handled either on a case-by-case basis or by generically-typed stubs.
Additionally the CPU, memory, and storage constraints are optimised for each use case. From a maintenance perspective, @TysonAndre and I do a pretty good job of keeping our copies of the signature map in sync, and would welcome any additional information.
cc @Majkl578 @carusogabriel @greg0ire