-
Notifications
You must be signed in to change notification settings - Fork 22.6k
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
Emit std::string instead of c10::string_view for Lazy IR class #74029
Conversation
CI Flow Status⚛️ CI FlowRuleset - Version:
|
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 46df399 (more details on the Dr. CI page):
🕵️ 1 new failure recognized by patternsThe following CI failures do not appear to be due to upstream breakages: linux-xenial-py3.7-gcc5.4 / test (backwards_compat, 1, 1, linux.2xlarge) (1/1)Step: "Test" (full log | diagnosis details | 🔁 rerun)
|
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.
LGTM.
tools/codegen/dest/lazy_ir.py
Outdated
@@ -105,7 +105,7 @@ def gen(self, f: Union[NativeFunctionsGroup, NativeFunction]) -> List[str]: | |||
node_ctor_args = ", ".join([f"const {i.cpp_type()}& {i.name}" for i in all_types]) | |||
scalar_initializers = ",\n ".join([f"{t.name}({t.name})" for t in scalar_types]) | |||
comma_if_scalar_initializers = ",\n" if len(scalar_initializers) else "" | |||
scalar_decls = "\n ".join([f"{t.cpp_type()} {t.name};" for t in scalar_types]) | |||
scalar_decls = "\n ".join([f"std::string {t.name};" if t.cpp_type() == "c10::string_view" else f"{t.cpp_type()} {t.name};" for t in scalar_types]) |
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.
i do want the lint to pass so the line can't be too long
more importantly, i think we should probably fix this inside the data model (basically, t.cpp_type() should probably return std::string for us)
its fine to land this without updating the data model, but it might be easy to do that at the same time.
please TAL at my refactor PR #73939 - it might be easier to modify the data model after that PR lands, or reviewing it might help your understanding of the data model
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.
I will break the line to pass lint.
Having t.cpp_type() return c10::string_view seems more consistent with other types. E.g. there is another call to cpp_type() at Line 105, which result seems more natural because the parameter is declared as const c10::string_view&
and the passed-in variable is also declared as c10::string_view at the callsite in core.
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.
I will merge the diff now and update it 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.
nice find. this is an ugly bug! i wonder if we have any other bugs like this. it would be easy enough to review the types we are using in our IR and make sure all of them seem correctly copied into owning memory.
Summary: c10::string_view may be pointing to a temp string, which is not guaranteed to be valid when accessed later, so we store the passed-in string_view into a string.
5814817
to
46df399
Compare
Summary: c10::string_view may be pointing to a temp string, which is not
guaranteed to be valid when accessed later, so we store the passed-in
string_view into a string.
Fixes #73963