Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

query re: non-built-in extension functions #2620

Open
SignpostMarv opened this issue Jan 14, 2020 · 11 comments
Open

query re: non-built-in extension functions #2620

SignpostMarv opened this issue Jan 14, 2020 · 11 comments
Labels

Comments

@SignpostMarv
Copy link
Contributor

If I were to patch in ext-imap stubs, is there a way that gets the function stubs into scope only if the extension is loaded or if the extension is not loaded but the code is inside an if (extension_loaded('imap')) {} condition- similar to the xdebug stub, except without it being manual?

@psalm-github-bot
Copy link

Hey @SignpostMarv, can you reproduce the issue on https://psalm.dev ?

@SignpostMarv
Copy link
Contributor Author

Hey @SignpostMarv, can you reproduce the issue on https://psalm.dev ?

nope, see weirdan/psalm-github-bot#22

@TysonAndre
Copy link
Contributor

One option would be to implement an option in psalm.xml mapping extension names to the path of a file to use if the extension isn't loaded.

In addition to that, add a tool to generate stubs from an environment where the extension is enabled - https://github.com/phan/phan/blob/master/tool/make_stubs is how Phan does that.

Phan has a similar config option to what you're requesting, which may be useful to refer to when implementing this

    // You can put paths to internal stubs in this config option.
    // Phan will continue using its detailed type annotations, but load the constants, classes, functions, and classes (and their Reflection types) from these stub files (doubling as valid php files).
    // Use a different extension from php to avoid accidentally loading these.
    // The 'mkstubs' script can be used to generate your own stubs (compatible with php 7.0+ right now)
    'autoload_internal_extension_signatures' => [
        'ast'         => '.phan/internal_stubs/ast.phan_php',
        'ctype'       => '.phan/internal_stubs/ctype.phan_php',
        'igbinary'    => '.phan/internal_stubs/igbinary.phan_php',
        'mbstring'    => '.phan/internal_stubs/mbstring.phan_php',
        'pcntl'       => '.phan/internal_stubs/pcntl.phan_php',
        'posix'       => '.phan/internal_stubs/posix.phan_php',
        'readline'    => '.phan/internal_stubs/readline.phan_php',
        'sysvmsg'     => '.phan/internal_stubs/sysvmsg.phan_php',
        'sysvsem'     => '.phan/internal_stubs/sysvsem.phan_php',
        'sysvshm'     => '.phan/internal_stubs/sysvshm.phan_php',
    ],

@weirdan
Copy link
Collaborator

weirdan commented Jan 14, 2020

mapping extension names to the path of a file to use if the extension isn't loaded.

I think what's @SignpostMarv is describing is exactly the opposite: a stub that has to be loaded if the extension is loaded. Type information available via reflection is often not enough for what Psalm is doing, so Psalm have to use stubs, CallMap.php, etc.

@SignpostMarv
Copy link
Contributor Author

@weirdan yes but also if it is not actually loaded but is inside a matching condition.

@TysonAndre
Copy link
Contributor

a stub that has to be loaded if the extension is loaded.

Oh, missed that part of the issue description.

bapcltd-marv added a commit to bapcltd/php-imap that referenced this issue Jan 15, 2020
bapcltd-marv added a commit to bapcltd/php-imap that referenced this issue Jan 15, 2020
bapcltd-marv added a commit to bapcltd/php-imap that referenced this issue Jan 15, 2020
bapcltd-marv added a commit to bapcltd/php-imap that referenced this issue Jan 15, 2020
@SignpostMarv
Copy link
Contributor Author

@TysonAndre @weirdan it occurs to me that the baseline attribute I added in #1936 could be a source of which stubs to load regardless of which extensions were actually loaded?

@AndrolGenhald
Copy link
Collaborator

Part of this is accomplished with #7107. I'd love to conditionally load stubs for specific contexts to support if (extension_loaded(...)) {, but that's going to be more difficult.

@SignpostMarv
Copy link
Contributor Author

Part of this is accomplished with #7107. I'd love to conditionally load stubs for specific contexts to support if (extension_loaded(...)) {, but that's going to be more difficult.

One would assume that doing a #2133 for all the things would spam up the config too much.

Or are you referring to avoiding RedundantCondition being flagged if the stub is always present?

@AndrolGenhald
Copy link
Collaborator

#7107 uses extensions required in composer.json to decide whether to enable them. I was referring to:

is there a way that gets the function stubs into scope only if the extension is loaded

The conditionally loading part is a lot more difficult, but it would be very nice to have.

@alies-dev
Copy link
Contributor

on a sidenote: I think imap should be moved callmaps to a separate stub as we did with other extensions not available by default:
image

ps: this will not solve the original issue of course

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants