jsii requires the wrong type in some cases #3818
Comments
otaviomacedo
added
bug
RomainMuller
added
p1
and removed
needs-triage
|
|
All parameters that have been reported as problematic are effectively forward declared, and it seems these get incorrectly resolved as part of the runtime (likely due to differences in globals, etc...). It seems like what we need to do is one of the following (need to check what works):
|
|
Foregoing the forward declaration appears to fix the issue, so I'll give this a shot. This also means this issue is a code-generator issue, and not a runtime issue, so broken libraries will only be fixed when generated with a fixed version of |
Since dae724c, Python type-checking relies on a nested stub function as a type annotations source. The parameter signature of that stub was copied verbatim from the surrounding function, including any forward type references. However, the forward references can safely be replaced with regular type references as the module is guaranteed to be fully loaded by the time the stub is created, and using forward-references there results in `typeguard` possibly evaluating those in a different context than the one where the surrounding function was defined. The consequence of this is that multiple different foward references by the same name may be incorrectly treated as referring to the same type, despite coming from different modules. This is fixed by turning forward type references in the stub with regular type references (in other words, removing any `"` from the parameter signature of the stub), which lets the type be resolved from the local definition context instead of the final runtime context in which the function is called. Fixes #3818
Since dae724c, Python type-checking relies on a nested stub function as a type annotations source. The parameter signature of that stub was copied verbatim from the surrounding function, including any forward type references. However, the forward references can safely be replaced with regular type references as the module is guaranteed to be fully loaded by the time the stub is created, and using forward-references there results in `typeguard` possibly evaluating those in a different context than the one where the surrounding function was defined. The consequence of this is that multiple different foward references by the same name may be incorrectly treated as referring to the same type, despite coming from different modules. This is fixed by turning forward type references in the stub with regular type references (in other words, removing any `"` from the parameter signature of the stub), which lets the type be resolved from the local definition context instead of the final runtime context in which the function is called. Fixes #3818 --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
|
Describe the bug
jsii requires the wrong type in some cases. Examples:
aws/aws-cdk#22688
aws/aws-cdk#22689
aws/aws-cdk#22711This behavior started with jsii 1.70.0.
Expected Behavior
Require the correct types.
Current Behavior
Example: in CDK 2.48.0+, typeguard in Python is requiring that the
Protocolparameter ofelasticloadbalancingv2.HealthCheckis of typeecs.Protocol, notelasticloadbalancingv2.Protocolas it was in CDK 2.47.0 and older.Reproduction Steps
Use one of the CDK bugs posted above to reproduce the issue.
Possible Solution
No response
Additional Information/Context
No response
SDK version used
N/A
Environment details (OS name and version, etc.)
MacOS
The text was updated successfully, but these errors were encountered: