-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-22668][SQL] Ensure no global variables in arguments of method split by CodegenContext.splitExpressions() #20021
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
Changes from 1 commit
18ec598
f1afb92
3d44195
95d0c1b
900f246
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -930,6 +930,18 @@ class CodegenContext { | |
| // inline execution if only one block | ||
| blocks.head | ||
| } else { | ||
| if (Utils.isTesting) { | ||
| // Passing global variables to the split method is dangerous, as any mutating to it is | ||
| // ignored and may lead to unexpected behavior. | ||
| // We don't need to check `arrayCompactedMutableStates` here, as it results to array access | ||
|
||
| // code and will raise compile error if we use it in parameter list. | ||
| val mutableStateNames = inlinedMutableStates.map(_._2).toSet | ||
| arguments.foreach { case (_, name) => | ||
| assert(!mutableStateNames.contains(name), | ||
| s"split function argument $name cannot be a global variable.") | ||
| } | ||
| } | ||
|
|
||
| val func = freshName(funcName) | ||
| val argString = arguments.map { case (t, name) => s"$t $name" }.mkString(", ") | ||
| val functions = blocks.zipWithIndex.map { case (body, i) => | ||
|
|
||
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.
Do we only do the assert in testing? Because passing global variables won't raise compile error, if we have any global variables passed in when not in testing, the codegen still work and may lead to wrong result.
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.
as you said, it may lead, but likely it doesn't. Then I do think that the best option is to assert it only in testing, where this might help finding potential bugs. In production it is an overkill to throw an exception for a situation which most likely is not a problem IMHO.
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.
Here is a discussion about this testing.