This patch adds the file names to llvm-objcopy error messages. It makes easy to identify which file causes an error.
Details
- Reviewers
• espindola alexander-shaposhnikov rupprecht jhenderson jakehehrlich - Commits
- rZORG69c27398d320: [llvm-objcopy] Add file names to error messages
rG69c27398d320: [llvm-objcopy] Add file names to error messages
rGada9d2d88464: [llvm-objcopy] Add file names to error messages
rL361450: [llvm-objcopy] Add file names to error messages
Diff Detail
Event Timeline
We need to remove unwrapOrError in the file parser [1] as well to print the file name in parsing errors. Removing unwrapOrError and return Error instead sounds straightforward to me but it could make the code messy. I'd like to hear your comments.
With a lot of the tests, it might be nice to make sure the file name matches exactly. This can be achieved using FileCheck patterns and command-line options like so:
# RUN: yaml2obj %s > %t.o # RUN: not llvm-objcopy %t.o %t2.o <options> | FileCheck %s -DFILE=%t.o # CHECK: error: [[FILE]]: error message...
This makes sure we use the right filename in the error, either the input or output filename.
Another thing is that you should make sure that all the code paths you modified are tested where possible. The tests probably already exist, and just need updating to check that the filename appears.
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
---|---|---|
691 | I don't have a problem with this change, but why did you make it? Also, it should probably be a separate patch, since it's not related to the bug you are trying to fix. | |
740–744 | Rather than create the file error here, it might make more sense to call createFileError in findBuildId. | |
754 | linkToBuildIdDir already calls createFileError in some situations. Rather than repeat it here, it would be better to change any necessary return sites in that function. |
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
---|---|---|
691 | I changed this to print the output file name specified in --dump-section because, for instance, creating the output file named File may fail with an EISDIR error. I'll remove this line and submit another patch to update this. | |
740–744 | Indeed. I'll change findBuildId to take Config and return a FileError from it. | |
754 | I thought it would be helpful to print the input file name but now realized that it is not so helpful. I'll remove this change and return the error from this function as it is because it already includes the file name which caused the error. |
- Applied feedbacks from James.
- Update tests to check if the error message contains the file name.
I noticed that this patch does not include the updates to dump-section.test. I'll update soon.
LGTM, but I'd like a second pair of eyes on it from someone like @MaskRay, @rupprecht, or @jakehehrlich before this goes in. I assume you'll need somebody to commit it for you?
Awesome. LGTM. Tell me if you want me or someone else to land it. You can also email Chris Latner to get access yourself.
You mean a write access to SVN as described here? https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
Yes, since you're now making regular patches.
I'll try to get around to committing this later today, but I've got some critical things to do today, so it might need to wait until @jakehehrlich gets in later.
I'm guessing we have more tests that could use the -DINPUT method here to verify the file is there in the error. This patch LGTM though. Thanks!
Changes in 5316a0d200f8 conflicts with this patch. Should I upload this patch again here for review or should I simply resolve conflicts and push to the repository?
Use your own judgement. If the changes require significant effort to fix, then feel free to provide an updated diff, but if not, you don't need to.
I see. I'll resolve conflicts and commit this patch without uploading here since it only changes the error messages.
I don't have a problem with this change, but why did you make it? Also, it should probably be a separate patch, since it's not related to the bug you are trying to fix.