Skip to content

feat(deducer): support evaluating the values of literal types and direct calls to data class constructors - #150

Merged
jianzs merged 1 commit into
pluto-lang:feat-support-pythonfrom
jianzs:feat-python-support
Mar 8, 2024
Merged

feat(deducer): support evaluating the values of literal types and direct calls to data class constructors#150
jianzs merged 1 commit into
pluto-lang:feat-support-pythonfrom
jianzs:feat-python-support

Conversation

@jianzs

Copy link
Copy Markdown
Contributor

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix#123", "re #123".):

  • N
  • Y

re #146

2. What is the scope of this PR (e.g. component or file name):

  • Pyright Deducer

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Other

For now, we're only able to evaluate the values of literal types and direct calls to data class constructors. For example, we can evaluate the following code:

num_1=1str_1="str1"bool_1=Truenull_1=Nonenum_2=num_1+1str_2=str_1+"str2""str2_plus"nested_mix_tuple_1= ((1, "str8", True), (2, "str9", False))
Model(base=Base("name", age=19), gender="male", nullable=null_1)

There are a couple of scenarios where we hit a brick wall:

  1. Values that could change on the fly — think of those unpredictable elements like the output from a random function or a timestamp. We just can't evaluate their values during static analysis.
  2. Values that shift depending on where you are in the call chain, such as the arguments accessed within a function. Take the example below: we're building a resource object inside a function body, and there's just no way for us to deduce the actual value of the variable fed into the constructor, which in this case is queueName.
defcreateQueue(queueName: str): returnQueue(queueName) 

In the first scenario, since we can't determine the real-time values during static analysis, we'll throw an error to flag it. As for the second, we're going to need future updates to trace through the call chains and make sense of those values.

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

  • N
  • Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

  • Unit test
  • Integration test
  • Benchmark (add benchmark stats below)
  • Manual test (add detailed scripts or steps below)
  • Other

@jianzsjianzs added the deducer Deducer label Mar 8, 2024
@jianzs
jianzs requested a review from PeefyMarch 8, 2024 03:31
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: cf209b8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@PeefyPeefy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jianzs
jianzs merged commit 042ab99 into pluto-lang:feat-support-pythonMar 8, 2024
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

deducerDeducer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@jianzs@Peefy