-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: Explicit @psalm-param handling #39
Conversation
This breaks Talk again:
I moved the "unsupported const" to psalm types to not break the openapi definition while the extractor does not support it and listed the plain list of integers on the normal type: Can we catch the exception and ignore it if another type was given, until constants are understood? |
Not great, but I guess the only way right now. Let's still print it as a warning though. |
The problem of being in the middle of 2 evolutions :)
Sounds okay for me atm |
ce8de1d
to
89c827e
Compare
Testing this with Talk now shows some unimplemented types like |
89c827e
to
2303976
Compare
So time to do the fixups and merge? |
Signed-off-by: jld3103 <jld3103yt@gmail.com>
Signed-off-by: jld3103 <jld3103yt@gmail.com>
65eaab6
to
12faea2
Compare
Ah too bad I forgot to remove the stacktrace from the log |
We can remove it when we add the verbose flag |
Fixes #32
Both
@param
and@psalm-param
were already parsed, but if both are present only the first was used. Now it considers both if both are present.