[PATCH] Teach CC1 to dump module dependencies to a directory
Justin Bogner
mail at justinbogner.com
Thu Jun 19 11:53:33 PDT 2014
Ben Langmuir <blangmuir at apple.com> writes:
> On Jun 19, 2014, at 10:31 AM, Justin Bogner <mail at justinbogner.com> wrote:
>
> Ben Langmuir <blangmuir at apple.com> writes:
>
> Hi Justin,
>
> Thanks for working on this! It’s looking pretty close.
>
> +/// Append the absolute path in Nested to the path given by Root.
> This will
> +/// remove directory traversal from the resulting nested path.
> +static void appendNestedPath(SmallVectorImpl<char> &Root,
> + SmallVectorImpl<char> &Nested) {
> + using namespace llvm::sys;
> + SmallVector<StringRef, 16> ComponentStack;
> +
> + StringRef Rel = path::relative_path(StringRef(Nested.begin(),
> Nested.size()));
>
> You seem to have manually inlined Nested.str() ;-) Maybe just make
> your Nested parameter a StringRef?
>
> Right, not sure what I was thinking there :). I'll pass in a StringRef
> instead.
>
> + // We need an absolute path to append to the root.
> + SmallString<256> AbsoluteSrc = Src;
> + fs::make_absolute(AbsoluteSrc);
> + // Build the destination path.
> + SmallString<256> Dest = Collector.getDest();
> + size_t RootLen = Dest.size();
> + appendNestedPath(Dest, AbsoluteSrc);
>
> Do we need to escape this somehow on Windows, since you might get C:
> in the middle of your path?
>
> And in general, will this work if Dest ends with a path separator?
> Then you would end up with // in the middle, which could potentially
> be eaten at some point (not sure).
>
> The call to path::relative_path in appendNestedPath takes care of both
> of these issues. It's strips off root_name (ie, C:) and root_directory
> (ie, /).
>
> It sure does, silly me.
>
> +bool ModuleDependencyListener::visitInputFile(StringRef Filename,
> bool IsSystem,
> + bool IsOverridden)
> {
> + if (!Collector.insertSeen(Filename))
> + return true;
> + if (copyToRoot(Filename))
> + Collector.setHasErrors();
> + return true;
> +}
>
> This is clearer to me if you invert the first if, but you decide.
> if (Collector.insertSeen(Filename))
> if (copyToRoot(Filename))
> Collector.setHasErrors();
> return true;
>
> Sure, I'm happy with either.
>
> +// RUN: find %t/vfs -type f | FileCheck %s -check-prefix=DUMP
> +// DUMP: AlsoDependsOnModule.framework/Headers/
> AlsoDependsOnModule.h
> +// DUMP:
> Module.framework/Frameworks/SubFramework.framework/Headers/
> SubFramework.h
>
> REQUIRES: shell, since you need ‘find’. This applies to both tests.
> Also you won’t get the path separators you expect on Windows.
>
> Hmm. Is there a good way to check if the files are created without find?
> Assuming there is, I'll change it use regex for the path separators, as
> I think the extra platform coverage here is worthwhile.
>
> I can’t think of a cleaner way to do this.
>
> This isn’t really the place to discuss llvm patches, but...
>
> + char *Buf = new char[BufSize];
>
> If you don’t want to put 4 KB on the stack, how about std::vector with
> its data() method?
>
> Yeah, 4k seemed like a bit much for the stack (though, this is always a
> leaf call, so maybe it's fine).
>
> Is a vector really better here? Since I have to manually manage closing
> the files anyway, the new/delete doesn't feel out of place, and using a
> std::vector or a std::unique_ptr purely as an RAII container muddies up
> what this is doing a bit.
>
> I don’t feel strongly about it, so go with what you have.
>
> + for (;;) {
> + Bytes = read(ReadFD, Buf, BufSize);
> + if (Bytes <= 0)
> + break;
> + Bytes = write(WriteFD, Buf, Bytes);
> + if (Bytes <= 0)
> + break;
> + }
>
> This doesn’t seem sufficiently paranoid about the number of bytes
> actually written by ‘write’.
>
> Right. This should probably loop on the write as well. I'll update that.
New patches attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-0001-Frontend-Add-a-CC1-flag-to-dump-module-dependencies.4.patch
Type: text/x-patch
Size: 15595 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140619/83ce657d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-0001-Support-Add-llvm-sys-fs-copy_file.3.patch
Type: text/x-patch
Size: 2472 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140619/83ce657d/attachment-0001.bin>
More information about the cfe-commits
mailing list