Skip to content
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

Should mergedParsedLibraries always emit an error ? #69112

Closed
nicolasvasilache opened this issue Oct 15, 2023 · 7 comments · Fixed by #69331
Closed

Should mergedParsedLibraries always emit an error ? #69112

nicolasvasilache opened this issue Oct 15, 2023 · 7 comments · Fixed by #69331

Comments

@nicolasvasilache
Copy link
Contributor

nicolasvasilache commented Oct 15, 2023

In #68661, @ftynse notes

Is it necessarily a verification error? Also, hasn't mergeSymbolsInto already emitted a more precise diagnostic?

about the following:

return mergedParsedLibraries->emitError()
               << "failed to verify merged transform module";
@ingomueller-net
Copy link
Contributor

Proposed fix: #69331.

Note that the PR currently still emits another error. I think that it can be helpful to have some context for the precise error. (I wonder whether the function should return InFlightDiagnostics instead of LogicalResult...? That doesn't seem to be a common pattern, though...)

@ftynse
Copy link
Member

ftynse commented Oct 17, 2023

It cannot remove InFlightDiagnostic. It emits the message in the destructor, which may or may not get called on return depending on copy elision. That's (partially) why we have DiagnosedSilenceableFailure in the transform dialect infrastructure. That carries a diagnostic that is explicitly reportable. But it is more expensive. If we definitely want to emit an diagnostic, we should do that in a place that has the most context and just propagate failure(). Otherwise, we can use DiagnosedSilenceableFailure in TD library or, alternatively, pass in an optional callback for error emission.

@joker-eph
Copy link
Collaborator

It emits the message in the destructor, which may or may not get called on return depending on copy elision.

You can always move explicitly?

@ftynse
Copy link
Member

ftynse commented Oct 18, 2023

return std::move(...) prevents elision so the destructor is always called. Did you mean something else?

@joker-eph
Copy link
Collaborator

This is what I mean: C++17 guarantees copy-elision in many cases, in the case where it does not you can move instead: the destructor will be called but that shouldn't have any effect on a diagnostic that has been moved from.

@ingomueller-net
Copy link
Contributor

I sounds like the conclusion is to have mergeSymbolsInto return an InFlightDiagnostics and attach the additional information there. Did I get that right?

@ingomueller-net
Copy link
Contributor

I sounds like the conclusion is to have mergeSymbolsInto return an InFlightDiagnostics and attach the additional information there. Did I get that right?

I modified #69331 to implement to what I understood is the suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants