zturner added a comment.
In https://reviews.llvm.org/D53532#1276463, @JDevlieghere wrote:
> Thanks for the feedback! I totally agree it's a good solution and it was one
> of the things I considered. It didn't make it to the top of the list because
> it is very intrusive and changes the semantic
JDevlieghere added a comment.
Thanks for the feedback! I totally agree it's a good solution and it was one of
the things I considered. It didn't make it to the top of the list because it is
very intrusive and changes the semantics of FileSpec quite a bit (i.e. it
becomes a PathSpec as Zachary n
zturner added a comment.
I envision `FileSpec` as being more of a `PathSpec`. It should be able
manipulate paths as strings and nothing more. There is indeed some logic that
still remains that resolves paths, but it manages to do this using LLVM's file
system APIs and the only reason it's sti
JDevlieghere added a comment.
While I don't disagree with the proposed approach, it needs to be highlighted
that extracting all file system operations would be very intrusive.
- Almost all logic in FileSpec deals with the filesystem. You can't even
resolve a path without it. How do you imagine
labath added a comment.
I also think it we should try to keep FileSpec in the Utility module. We should
be able to do that by deleting the "utility" functions in the FileSpec class,
and updating everything to go through the FileSystem class.
After the VFS introduction, something like `file_spec
Sent from my iPhone
> On Oct 24, 2018, at 7:05 PM, Zachary Turner wrote:
>
> It seems like FileSpec was moved out of Utility and into Host. I’m not a fan
> of this change, because it took a lot of effort to get it into Utility, which
> helped break a lot of bad dependencies. Can we invert th
zturner added a subscriber: JDevlieghere.
zturner added a comment.
It seems like FileSpec was moved out of Utility and into Host. I’m not a
fan of this change, because it took a lot of effort to get it into Utility,
which helped break a lot of bad dependencies. Can we invert this dependency
and mo
It seems like FileSpec was moved out of Utility and into Host. I’m not a
fan of this change, because it took a lot of effort to get it into Utility,
which helped break a lot of bad dependencies. Can we invert this dependency
and move FileSpec back into Utility?
On Wed, Oct 24, 2018 at 5:53 PM Jonas
JDevlieghere added a comment.
Note that there's also a File class which we'll need to patch up separately
together with all other uses that actually open or read a file. For this class
we can do the same as we did for FileSpec: deferring relevant operations to the
FileSystem class.
https://re
labath added a comment.
Back when the FileSystem class was introduced, the idea was that *it* would
eventually become the gateway to the real filesystem, and FileSpec would just
deal with abstract path manipulation.
I still think that is a good idea, particularly in light of this patch. So I
w
JDevlieghere created this revision.
JDevlieghere added reviewers: zturner, labath, clayborg.
JDevlieghere added a project: LLDB.
This patch adds support for virtual file systems by delegating relevant
operations. By default the real file system is used so this should be NFC for
all intents and p
11 matches
Mail list logo
