Closed by commit rL201905 (authored by @benlangmuir).
CHANGED PRIOR TO COMMIT
http://llvm-reviews.chandlerc.com/D2835?vs=7290&id=7292#toc
http://llvm-reviews.chandlerc.com/D2835
COMMIT
http://llvm-reviews.chandlerc.com/rL201905
___
cfe-commits m
Comment at: unittests/Basic/VirtualFileSystemTest.cpp:253-254
@@ +252,4 @@
+
+TEST(VirtualFileSystemTest, MappedFiles) {
+ NumDiagnostics = 0;
+ IntrusiveRefCntPtr Lower(new DummyFileSystem());
Dmitri Gribenko wrote:
> You could use TEST_F to create a test fixt
LGTM!
On Feb 21, 2014, at 2:22 PM, Ben Langmuir wrote:
> Changes per review feedback. Interesting changes are:
>
> * new version field, and tests that check that it exists (and is currently 0)
> * diagnostics are now counted in tests
> * normalizePath is gone; . and .. entries will not wor
LGTM.
Comment at: unittests/Basic/VirtualFileSystemTest.cpp:253-254
@@ +252,4 @@
+
+TEST(VirtualFileSystemTest, MappedFiles) {
+ NumDiagnostics = 0;
+ IntrusiveRefCntPtr Lower(new DummyFileSystem());
You could use TEST_F to create a test fixture. Then you d
Changes per review feedback. Interesting changes are:
* new version field, and tests that check that it exists (and is currently 0)
* diagnostics are now counted in tests
* normalizePath is gone; . and .. entries will not work (but they didn't
*really* work in my previous patch either.
On Feb 21, 2014, at 11:13 AM, Dmitri Gribenko wrote:
> On Fri, Feb 21, 2014 at 5:55 PM, Ben Langmuir wrote:
>> At this point, the solution I hate the least is to use a regular field, and
>> cheat the JSON spec by requiring it to come first. If no one hates that,
>> I’ll go with it.
>
> I do
On Fri, Feb 21, 2014 at 5:55 PM, Ben Langmuir wrote:
> At this point, the solution I hate the least is to use a regular field, and
> cheat the JSON spec by requiring it to come first. If no one hates that,
> I’ll go with it.
I don't think there is a need to require 'version' to be the first
fi
On Feb 21, 2014, at 9:24 AM, Argyrios Kyrtzidis wrote:
>
> On Feb 21, 2014, at 9:09 AM, Dmitri Gribenko wrote:
>
>> On Fri, Feb 21, 2014 at 5:02 PM, Argyrios Kyrtzidis
>> wrote:
>>> The problem with a simple JSON field is that it is not clear that we are
>>> depending on the presence of so
On Fri, Feb 21, 2014 at 5:19 PM, Ben Langmuir wrote:
> Is that in the YAML spec somewhere? I don’t see it. There was something
> about not relying on the name of a tag handle, but I’m willing to be
> non-conformant in that respect. Obviously this is not what YAML tags were
> designed for…
I
On Feb 21, 2014, at 9:09 AM, Dmitri Gribenko wrote:
> On Fri, Feb 21, 2014 at 5:02 PM, Argyrios Kyrtzidis
> wrote:
>> The problem with a simple JSON field is that it is not clear that we are
>> depending on the presence of something at the beginning of the file in order
>> to interpret it as
On Feb 21, 2014, at 9:02 AM, Argyrios Kyrtzidis wrote:
>
> On Feb 21, 2014, at 3:27 AM, Dmitri Gribenko wrote:
>
>> On Fri, Feb 21, 2014 at 12:34 AM, Ben Langmuir wrote:
>>>
>>> On Feb 20, 2014, at 4:11 PM, Ben Langmuir wrote:
We could use the YAML version string
%YAML 1.2
>>>
>
On Fri, Feb 21, 2014 at 5:02 PM, Argyrios Kyrtzidis wrote:
> The problem with a simple JSON field is that it is not clear that we are
> depending on the presence of something at the beginning of the file in order
> to interpret it as JSON.
> It is more clear to say
> the file should have
On Feb 21, 2014, at 3:27 AM, Dmitri Gribenko wrote:
> On Fri, Feb 21, 2014 at 12:34 AM, Ben Langmuir wrote:
>>
>> On Feb 20, 2014, at 4:11 PM, Ben Langmuir wrote:
>>> We could use the YAML version string
>>> %YAML 1.2
>>
>> Actually, if we go this route we should encode our own version numbe
On Fri, Feb 21, 2014 at 12:34 AM, Ben Langmuir wrote:
>
> On Feb 20, 2014, at 4:11 PM, Ben Langmuir wrote:
>> We could use the YAML version string
>> %YAML 1.2
>
> Actually, if we go this route we should encode our own version number in the
> same place for compactness. In YAML, we could use a
On Feb 20, 2014, at 4:34 PM, Ben Langmuir wrote:
>
> On Feb 20, 2014, at 4:11 PM, Ben Langmuir wrote:
>
>>
>> On Feb 20, 2014, at 11:22 AM, Argyrios Kyrtzidis wrote:
>>
>>> On Feb 20, 2014, at 10:02 AM, Ben Langmuir wrote:
>>>
> I think it is better to move the YAML VFS descrip
On Feb 20, 2014, at 4:11 PM, Ben Langmuir wrote:
>
> On Feb 20, 2014, at 11:22 AM, Argyrios Kyrtzidis wrote:
>
>> On Feb 20, 2014, at 10:02 AM, Ben Langmuir wrote:
>>
>>>
I think it is better to move the YAML VFS description to a new file under
'docs/'. This file format is API,
On Feb 20, 2014, at 11:22 AM, Argyrios Kyrtzidis wrote:
> On Feb 20, 2014, at 10:02 AM, Ben Langmuir wrote:
>
>>
>>> I think it is better to move the YAML VFS description to a new file under
>>> 'docs/'. This file format is API, and should be documented.
>>
>> Can this wait until we have mo
> Can this wait until we have more practical experience with the file format?
Things in docs/ tend to have better documentation that what I've written here,
and I don't want to put a lot of effort into this until we're sure this is the
right format.
OK, but I was asking about moving what i
On Feb 20, 2014, at 10:02 AM, Ben Langmuir wrote:
>
>> I think it is better to move the YAML VFS description to a new file under
>> 'docs/'. This file format is API, and should be documented.
>
> Can this wait until we have more practical experience with the file format?
> Things in docs/ te
> I think it is better to move the YAML VFS description to a new file under
'docs/'. This file format is API, and should be documented.
Can this wait until we have more practical experience with the file format?
Things in docs/ tend to have better documentation that what I've written here,
We also need to document how our case-insensitive matching interacts with
Unicode.
Comment at: lib/Basic/VirtualFileSystem.cpp:674-675
@@ +673,4 @@
+Status S = DE->getStatus();
+S.setName(PathStr);
+S.setExternalName(PathStr);
+return S;
Why d
I think it is better to move the YAML VFS description to a new file under
'docs/'. This file format is API, and should be documented.
Unrelated to this patch, but how do we keep track of the current working
directory? Or we don't just yet?
Comment at: lib/Basic/VirtualF
Hi akyrtzi,
Provides a way to create a virtual file system using a YAML file that
supports mapping a file to a path on an 'external' file system. The
external file system will typically be the 'real' file system, but for
testing it can be changed.
A future patch will add a clang option to allow t
23 matches
Mail list logo
