This is an archive of the discontinued LLVM Phabricator instance.

Update more `parseSourceString()` call sites.
ClosedPublic

Authored by csigg on Mar 7 2022, 3:43 AM.

Details

Summary

Change to non-deprecated function template (see D121075).

Diff Detail

Event Timeline

csigg created this revision.Mar 7 2022, 3:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2022, 3:43 AM
csigg requested review of this revision.Mar 7 2022, 3:43 AM
ftynse added a subscriber: ftynse.Mar 7 2022, 5:25 AM

The patch seems to include irrelevant bazel changes.

csigg updated this revision to Diff 413444.Mar 7 2022, 6:27 AM

Rebase.

rriddle accepted this revision.Mar 7 2022, 10:15 AM
rriddle added inline comments.
mlir/unittests/Transforms/Canonicalizer.cpp
78

Can we drop the mlir:: here?

This revision is now accepted and ready to land.Mar 7 2022, 10:15 AM

Hello @csigg, there seems to be another use of the deprecated parseSourceString function in mlir/lib/CAPI/IR/IR.cpp that is causing a deprecated error in our builds. Would you mind please updating that use as well? Thanks!

csigg updated this revision to Diff 413759.Mar 8 2022, 3:59 AM

Fix mlir/lib/CAPI/IR/IR.cpp as well.

csigg marked an inline comment as done.Mar 8 2022, 4:02 AM

Hello @csigg, there seems to be another use of the deprecated parseSourceString function in mlir/lib/CAPI/IR/IR.cpp that is causing a deprecated error in our builds. Would you mind please updating that use as well? Thanks!

Done.

Does that mean that we are not supposed to mark things deprecated?
Or would it make sense to only treat deprecations as warnings in your build?

This revision was automatically updated to reflect the committed changes.

Hello @csigg, there seems to be another use of the deprecated parseSourceString function in mlir/lib/CAPI/IR/IR.cpp that is causing a deprecated error in our builds. Would you mind please updating that use as well? Thanks!

Done.

Does that mean that we are not supposed to mark things deprecated?
Or would it make sense to only treat deprecations as warnings in your build?

Thanks for fixing the use. I was about to submit a change myself but saw that you had a similar one and decided to ask.
In this particular instance I thought it was better to fix the call site rather than ignore the warning / error. I can't speak to the preferences of the entire LLVM community, however.