-
Notifications
You must be signed in to change notification settings - Fork 101
fix(type system): Fix function closures not correctly updating TypeState
#1399
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
Open
Zettroke
wants to merge
11
commits into
vectordotdev:main
Choose a base branch
from
Zettroke:apply-function-closure-type-info
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
28b3b19
fix function closures not correctly updating `TypeState`
Zettroke b040cd7
add changelog entry
Zettroke 035c257
add test for function closures correctly updating `TypeState`
Zettroke 88cbde1
Merge remote-tracking branch 'origin/main' into apply-function-closur…
pront 9b04cf7
cargo fmt
pront 46c3368
rename changelog file
pront 425ebc9
make Vector integration check work with forks
pront 8b5e5a9
second attempt to fix the workflow
pront e2a0009
code improvements
pront 9a3ece7
Merge branch 'main' into apply-function-closure-type-info
Zettroke 893dc98
Update vector_integration_check.yaml
Zettroke File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| Function closures now correctly update type state of the program. | ||
|
|
||
| authors: zettroke |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can avoid
expects in this fucntion. See example: e2a0009.Also, do you have any example where this change can break existing behavior? I wonder if we should mark this as a breaking PR.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more of an invariant I tried to document by using
expect.The code in
Builder::check_closureis called earlier and adds these variables toTypeState. So if they are absent it means there is a bug.Maybe I should specify it in expect message?
As for examples of broken code, there is an example I found by scanning or VRL codebase.
Error:
The difference is in Kind of
elementsprobed atlog_state()point:current-vrl:
fixed-vrl:
So the second
for_eachdoesn't type check. I can probably make simpler example, but too tired right now 😄There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking the time to explain this. We should mark this as a breaking change and provide an example in the changelog. As always, there is no rush.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pront After some work of adapting our VRL code base to this fix I think I have a better example of broken code.
Error:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also found a trick to keep added error handling compatible with older vrl versions, though it's very ugly 😅
parsed_value = parse_json!("{}")Couldn't think of anything better :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I would be more comfortable if we included this in the next-next release. BTW I fixed
.github/workflows/vector_integration_check.yamlon main so you can just undo those changes.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the before and after types for the
value(inside the secondfor_eachclosure) here? And how doesparsed_value = parse_json!("{}")line changes the type? Just trying to understand if this behavior breakage makes sense before asking all users to change their VRL programs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Earlier example:
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parse_json!("{}")makes itany, sofor_eachcan't deduce the type of(key, value)pair. Therefore,it's type is
neverwhich forces the error handling.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Optional) Can you please add a "before and after" in the changelog? It would be very helpful for the next breaking guide and VRL users.