[PATCH] D85024: [llvm-objdump] Implement --prefix option

[James Henderson via Phabricator via llvm-commits]

jhenderson added inline comments.


================
Comment at: llvm/test/tools/llvm-objdump/X86/source-interleave-absolute-paths.test:29
+; RUN: llvm-objdump --prefix myprefix/// --source %t.o 2>&1 | FileCheck %s --check-prefix CHECK-TRAILING -DFILE=%t.o
+; CHECK-TRAILING: warning: '[[FILE]]': failed to find source myprefix/Inputs/source-interleave-x86_64.c
----------------
tinti wrote:
> jhenderson wrote:
> > tinti wrote:
> > > jhenderson wrote:
> > > > You don't need `CHECK-TRAILING`. You can use `CHECK-BROKEN-PREFIX` with `-D ROOT=''`.
> > > In this case I believe I need.
> > > 
> > > `CHECK-BROKEN-PREFIX` uses `%t2`.
> > > `CHECK-TRAILING` uses `%t`.
> > `CHECK-BROKEN-PREFIX` and `CHECK-TRAILING` do NOT use `%t` or `%t2`. What do you think the `-DFILE` bit of the FileCheck invocation does?
> > 
> > Please take this in the well-meaning way it's intended, but I'd highly recommend you read through the FileCheck documentation at https://llvm.org/docs/CommandGuide/FileCheck.html. It seems that you may have several misunderstandings about how FileCheck works.
> You can be crystal clear with me.
> 
> I red again the docs. Now it is more clear what you were saying.
> 
> There is no need to use `CHECK-TRAILING: warning: ...` because I can reuse `CHECK-BROKEN-PREFIX: warning: ...` with different parameters from `-D`.
> 
> My understanding was wrong. Given a RUN command, I thought FileCheck would only look for CHECKs after it.
Yes, exactly. Perhaps the best way to think about it is to imagine all the CHECK patterns in a separate file. FileCheck is just another process, which happens to take an input file to parse patterns from, and another input (via stdin or --input-file), which contains the text to check. By convention, the same file is used for the lit directives and the FileCheck patterns (hence '%s' in the FileCheck invocation, which means "this file"), but the lit directives (e.g. RUN lines) and FileCheck directives (CHECK lines) are actually completely unrelated and parsed by two separate processes, and thus have no bearing on one another.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85024/new/

https://reviews.llvm.org/D85024