r339074 - [lit, python] Always add quotes around the python path in lit

2018-08-06 Thread Stella Stamenova via cfe-commits
Author: stella.stamenova
Date: Mon Aug  6 15:37:45 2018
New Revision: 339074

URL: http://llvm.org/viewvc/llvm-project?rev=339074&view=rev
Log:
[lit, python] Always add quotes around the python path in lit

Summary:
The issue with the python path is that the path to python on Windows can 
contain spaces. To make the tests always work, the path to python needs to be 
surrounded by quotes.

This is a companion change to: https://reviews.llvm.org/D50206

Reviewers: asmith, zturner

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D50281

Modified:
cfe/trunk/test/Tooling/clang-diff-json.cpp

Modified: cfe/trunk/test/Tooling/clang-diff-json.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Tooling/clang-diff-json.cpp?rev=339074&r1=339073&r2=339074&view=diff
==
--- cfe/trunk/test/Tooling/clang-diff-json.cpp (original)
+++ cfe/trunk/test/Tooling/clang-diff-json.cpp Mon Aug  6 15:37:45 2018
@@ -1,10 +1,10 @@
 // RUN: clang-diff -ast-dump-json %s -- \
-// RUN: | '%python' -c 'import json, sys; 
json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True, indent=2)' \
+// RUN: | %python -c 'import json, sys; 
json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True, indent=2)' \
 // RUN: | FileCheck %s
 
-// CHECK: "begin": 301,
+// CHECK: "begin": 311,
 // CHECK: "type": "FieldDecl",
-// CHECK: "end": 321,
+// CHECK: "end": 319,
 // CHECK: "type": "CXXRecordDecl",
 class A {
   int x;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: [PATCH] D46485: Add python tool to dump and construct header maps

2018-06-20 Thread Stella Stamenova via cfe-commits
Thanks Bruno,

I ran a build as well and I can see that hmaptool is now in the correct bin 
directory. The tests still failed though because on Windows, at least, you need 
to explicitly call python to run a script e.g. "python hmaptool".

There are a few tests in LLVM that do that, for example:

; RUN: %python -c "print(' ' * 65536)" > %t.cache/llvmcache-foo

I am not sure whether you can simply call python on hmaptool or if you would 
have to include the fullpath to it though.

Thanks,
-Stella

-Original Message-
From: Bruno Cardoso Lopes  
Sent: Wednesday, June 20, 2018 4:14 PM
To: Stella Stamenova 
Cc: Richard Smith ; Duncan Exon Smith 
; jkor...@apple.com; mgo...@gentoo.org; cfe-commits 

Subject: Re: [PATCH] D46485: Add python tool to dump and construct header maps

Attempted a fix in r335190, watching the bots.
On Wed, Jun 20, 2018 at 3:53 PM Bruno Cardoso Lopes  
wrote:
>
> Hi Stella,
>
> On Wed, Jun 20, 2018 at 3:44 PM Stella Stamenova via Phabricator 
>  wrote:
> >
> > stella.stamenova added a comment.
> >
> > This breaks the clang tests on Windows when building using Visual Studio as 
> > none of the updated tests can find hmaptool.
>
> Yes. I contacted Galina about that but maybe it was the wrong person 
> to contact.
>
> > Visual Studio as a generator supports multiple configurations, so its bin 
> > folder varies depending on the build configuration. The generalized version 
> > of the bin directory is: ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin. This 
> > is actually the proper bin directory to use for any generator because 
> > ${CMAKE_CFG_INTDIR} is simply '.' when the generator (such as ninja) 
> > doesn't support multiple configurations.
>
> Good to know.
>
> > I can look into a fix and submit a change for review tomorrow if you can't, 
> > but in the future please make sure to use the full path to the bin 
> > directory (${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin) to avoid missing a 
> > generator.
>
> I'll try to fix it now. Thanks for the heads up!
>
> >
> >
> > Repository:
> >   rC Clang
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> > iews.llvm.org%2FD46485&data=02%7C01%7CSTILIS%40microsoft.com%7C83fc2
> > 84426aa4e51e2d908d5d70387cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> > C1%7C636651332530245571&sdata=yGlv3J3wsuEvQGDd3b7Kq8FU3dMqORS4eH8a%2
> > BL3ikzk%3D&reserved=0
> >
> >
> >
>
>
> --
> Bruno Cardoso Lopes
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.br
> unocardoso.cc&data=02%7C01%7CSTILIS%40microsoft.com%7C83fc284426aa4e51
> e2d908d5d70387cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63665133
> 2530245571&sdata=KwMaPuOYjHXndEiYOBVZY29vefhR3poMegBV4HCPaxk%3D&reserv
> ed=0



--
Bruno Cardoso Lopes
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.brunocardoso.cc&data=02%7C01%7CSTILIS%40microsoft.com%7C83fc284426aa4e51e2d908d5d70387cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636651332530245571&sdata=KwMaPuOYjHXndEiYOBVZY29vefhR3poMegBV4HCPaxk%3D&reserved=0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D46485: Add python tool to dump and construct header maps

2018-06-20 Thread Stella Stamenova via cfe-commits
Yes, I can try it out. Feel free to add me to the review as well.


From: Bruno Cardoso Lopes 
Sent: Wednesday, June 20, 2018 6:25 PM
To: Stella Stamenova
Cc: Richard Smith; Duncan Exon Smith; jkor...@apple.com; Michał Górny; 
cfe-commits
Subject: Re: [PATCH] D46485: Add python tool to dump and construct header maps

On Wed, Jun 20, 2018 at 5:42 PM Stella Stamenova  wrote:
>
> Thanks Bruno,
>
> I ran a build as well and I can see that hmaptool is now in the correct bin 
> directory. The tests still failed though because on Windows, at least, you 
> need to explicitly call python to run a script e.g. "python hmaptool".
>
> There are a few tests in LLVM that do that, for example:
>
> ; RUN: %python -c "print(' ' * 65536)" > %t.cache/llvmcache-foo
>
> I am not sure whether you can simply call python on hmaptool or if you would 
> have to include the fullpath to it though.

Oh, I see. I'll revert the commits while I find a solution for this.
Any chance you can give it a try before I re-commit if I send you an
updated patch?

Thanks,

--
Bruno Cardoso Lopes
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.brunocardoso.cc&data=02%7C01%7Cstilis%40microsoft.com%7C9a3d5b51b26c4ff1a8db08d5d715df88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651411307060645&sdata=2EamqaQFSd35ZIqp%2Ft9TxAUZYoeDg8NkD47VaERkoG8%3D&reserved=0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352252 - Fixed frontend clang tests in windows read-only container

2019-01-25 Thread Stella Stamenova via cfe-commits
Author: stella.stamenova
Date: Fri Jan 25 15:03:12 2019
New Revision: 352252

URL: http://llvm.org/viewvc/llvm-project?rev=352252&view=rev
Log:
Fixed frontend clang tests in windows read-only container

Summary:
When mounting LLVM source into a windows container in read-only mode, certain 
tests fail. Ideally, we want all these tests to pass so that developers can 
mount the same source folder into multiple (windows) containers simultaneously, 
allowing them to build/test the same source code using various different 
configurations simultaneously.

**Fix**: I've found that when attempting to open a file for writing on windows, 
if you don't have the correct permissions (trying to open a file for writing in 
a read-only folder), you get [Access is 
denied](https://support.microsoft.com/en-us/help/2623670/access-denied-or-other-errors-when-you-access-or-work-with-files-and-f).
 In llvm, we map this error message to a linux based error, see: 
https://github.com/llvm-mirror/llvm/blob/master/lib/Support/ErrorHandling.cpp

This is why we see "Permission denied" in our output as opposed to the expected 
"No such file or directory", thus causing the tests to fail.

I've changed the test locally to instead point to the root drive so that they 
can successfully bypass the Access is denied error when LLVM is mounted in as a 
read-only directory. This way, the test operate exactly the same, but we can 
get around the windows-complications of what error to expect in a read-only 
directory.

Patch By: justice_adams

Reviewers: rsmith, zturner, MatzeB, stella.stamenova

Reviewed By: stella.stamenova

Subscribers: ormris, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D50563

Modified:
cfe/trunk/test/Frontend/output-failures.c
cfe/trunk/test/Frontend/stats-file.c

Modified: cfe/trunk/test/Frontend/output-failures.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/output-failures.c?rev=352252&r1=352251&r2=352252&view=diff
==
--- cfe/trunk/test/Frontend/output-failures.c (original)
+++ cfe/trunk/test/Frontend/output-failures.c Fri Jan 25 15:03:12 2019
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -emit-llvm -o %S/doesnotexist/somename %s 2> %t
+// RUN: not %clang_cc1 -emit-llvm -o %T/doesnotexist/somename %s 2> %t
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -input-file=%t %s
 
-// OUTPUTFAIL: error: unable to open output file 
'{{.*}}{{[/\\]}}test{{[/\\]}}Frontend{{[/\\]}}doesnotexist{{[/\\]}}somename': 
'{{[nN]}}o such file or directory'
+// OUTPUTFAIL: error: unable to open output file 
'{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'

Modified: cfe/trunk/test/Frontend/stats-file.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/stats-file.c?rev=352252&r1=352251&r2=352252&view=diff
==
--- cfe/trunk/test/Frontend/stats-file.c (original)
+++ cfe/trunk/test/Frontend/stats-file.c Fri Jan 25 15:03:12 2019
@@ -4,5 +4,5 @@
 //  ... here come some json values ...
 // CHECK: }
 
-// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%T/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
 // OUTPUTFAIL: warning: unable to open statistics output file 
'{{.*}}doesnotexist{{.}}bla': '{{[Nn]}}o such file or directory'


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r348665 - [tests] Fix the FileManagerTest getVirtualFile test on Windows

2018-12-07 Thread Stella Stamenova via cfe-commits
Author: stella.stamenova
Date: Fri Dec  7 15:50:05 2018
New Revision: 348665

URL: http://llvm.org/viewvc/llvm-project?rev=348665&view=rev
Log:
[tests] Fix the FileManagerTest getVirtualFile test on Windows

Summary: The test passes on Windows only when it is executed on the C: drive. 
If the build and tests run on a different drive, the test is currently failing.

Reviewers: kadircet, asmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D55451

Modified:
cfe/trunk/unittests/Basic/FileManagerTest.cpp

Modified: cfe/trunk/unittests/Basic/FileManagerTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/FileManagerTest.cpp?rev=348665&r1=348664&r2=348665&view=diff
==
--- cfe/trunk/unittests/Basic/FileManagerTest.cpp (original)
+++ cfe/trunk/unittests/Basic/FileManagerTest.cpp Fri Dec  7 15:50:05 2018
@@ -351,22 +351,34 @@ TEST_F(FileManagerTest, makeAbsoluteUses
 
 // getVirtualFile should always fill the real path.
 TEST_F(FileManagerTest, getVirtualFileFillsRealPathName) {
+  SmallString<64> CustomWorkingDir;
+#ifdef _WIN32
+  CustomWorkingDir = "C:/";
+#else
+  CustomWorkingDir = "/";
+#endif
+
+  auto FS = IntrusiveRefCntPtr(
+  new llvm::vfs::InMemoryFileSystem);
+  // setCurrentworkingdirectory must finish without error.
+  ASSERT_TRUE(!FS->setCurrentWorkingDirectory(CustomWorkingDir));
+
+  FileSystemOptions Opts;
+  FileManager Manager(Opts, FS);
+
   // Inject fake files into the file system.
   auto statCache = llvm::make_unique();
   statCache->InjectDirectory("/tmp", 42);
   statCache->InjectFile("/tmp/test", 43);
-  manager.addStatCache(std::move(statCache));
+
+  Manager.addStatCache(std::move(statCache));
 
   // Check for real path.
-  const FileEntry *file = manager.getVirtualFile("/tmp/test", 123, 1);
+  const FileEntry *file = Manager.getVirtualFile("/tmp/test", 123, 1);
   ASSERT_TRUE(file != nullptr);
   ASSERT_TRUE(file->isValid());
-  SmallString<64> ExpectedResult;
-#ifdef _WIN32
-  ExpectedResult = "C:/";
-#else
-  ExpectedResult = "/";
-#endif
+  SmallString<64> ExpectedResult = CustomWorkingDir;
+
   llvm::sys::path::append(ExpectedResult, "tmp", "test");
   EXPECT_EQ(file->tryGetRealPathName(), ExpectedResult);
 }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: r348665 - [tests] Fix the FileManagerTest getVirtualFile test on Windows

2018-12-10 Thread Stella Stamenova via cfe-commits
Our tests run on drive E:\ (not C:\) which is why we saw this test failing. 
After this change, the test can now run successfully for us because the 
temporary files are created and checked for on the C:\ drive. Before this 
change, the temporary files were created on the E:\ drive and checked for on 
the C:\ drive.

Are you saying that you have a drive C:\ and the test is failing anyway? Or do 
you not even have a drive C:\?

Thanks,
-Stella

-Original Message-
From: Aaron Ballman  
Sent: Monday, December 10, 2018 6:55 AM
To: Stella Stamenova 
Cc: cfe-commits 
Subject: Re: r348665 - [tests] Fix the FileManagerTest getVirtualFile test on 
Windows

On Fri, Dec 7, 2018 at 6:52 PM Stella Stamenova via cfe-commits 
 wrote:
>
> Author: stella.stamenova
> Date: Fri Dec  7 15:50:05 2018
> New Revision: 348665
>
> URL: 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.
> org%2Fviewvc%2Fllvm-project%3Frev%3D348665%26view%3Drev&data=02%7C
> 01%7Cstilis%40microsoft.com%7Cc4e90b6970994d2b15b608d65eaf7ff3%7C72f98
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636800505193880574&sdata=vv0
> qe64wy0oqci7RAlCXHxmjREevqS3s%2ByNz83tqQIw%3D&reserved=0
> Log:
> [tests] Fix the FileManagerTest getVirtualFile test on Windows
>
> Summary: The test passes on Windows only when it is executed on the C: drive. 
> If the build and tests run on a different drive, the test is currently 
> failing.
>
> Reviewers: kadircet, asmith
>
> Subscribers: cfe-commits
>
> Differential Revision: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi
> ews.llvm.org%2FD55451&data=02%7C01%7Cstilis%40microsoft.com%7Cc4e9
> 0b6970994d2b15b608d65eaf7ff3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C636800505193880574&sdata=0dFS4XR2o85FyI0XHr9Eh4pX%2BbdC2CPhXdd
> X3lDYaao%3D&reserved=0
>
> Modified:
> cfe/trunk/unittests/Basic/FileManagerTest.cpp
>
> Modified: cfe/trunk/unittests/Basic/FileManagerTest.cpp
> URL: 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.
> org%2Fviewvc%2Fllvm-project%2Fcfe%2Ftrunk%2Funittests%2FBasic%2FFileMa
> nagerTest.cpp%3Frev%3D348665%26r1%3D348664%26r2%3D348665%26view%3Ddiff
> &data=02%7C01%7Cstilis%40microsoft.com%7Cc4e90b6970994d2b15b608d65
> eaf7ff3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63680050519388057
> 4&sdata=UkdKXFFYeXogiCIJ8%2B41qUFO2qON9seRUVYziL2%2B9Yg%3D&res
> erved=0 
> ==
> 
> --- cfe/trunk/unittests/Basic/FileManagerTest.cpp (original)
> +++ cfe/trunk/unittests/Basic/FileManagerTest.cpp Fri Dec  7 15:50:05 
> +++ 2018
> @@ -351,22 +351,34 @@ TEST_F(FileManagerTest, makeAbsoluteUses
>
>  // getVirtualFile should always fill the real path.
>  TEST_F(FileManagerTest, getVirtualFileFillsRealPathName) {
> +  SmallString<64> CustomWorkingDir;
> +#ifdef _WIN32
> +  CustomWorkingDir = "C:/";
> +#else
> +  CustomWorkingDir = "/";
> +#endif

Unfortunately, this is still an issue -- you cannot assume that C:\ is the 
correct drive letter on Windows. For instance, this unit test fails for me 
because it turns out to be D:\ on my system.

~Aaron

> +
> +  auto FS = IntrusiveRefCntPtr(
> +  new llvm::vfs::InMemoryFileSystem);  // 
> + setCurrentworkingdirectory must finish without error.
> +  ASSERT_TRUE(!FS->setCurrentWorkingDirectory(CustomWorkingDir));
> +
> +  FileSystemOptions Opts;
> +  FileManager Manager(Opts, FS);
> +
>// Inject fake files into the file system.
>auto statCache = llvm::make_unique();
>statCache->InjectDirectory("/tmp", 42);
>statCache->InjectFile("/tmp/test", 43);
> -  manager.addStatCache(std::move(statCache));
> +
> +  Manager.addStatCache(std::move(statCache));
>
>// Check for real path.
> -  const FileEntry *file = manager.getVirtualFile("/tmp/test", 123, 
> 1);
> +  const FileEntry *file = Manager.getVirtualFile("/tmp/test", 123, 
> + 1);
>ASSERT_TRUE(file != nullptr);
>ASSERT_TRUE(file->isValid());
> -  SmallString<64> ExpectedResult;
> -#ifdef _WIN32
> -  ExpectedResult = "C:/";
> -#else
> -  ExpectedResult = "/";
> -#endif
> +  SmallString<64> ExpectedResult = CustomWorkingDir;
> +
>llvm::sys::path::append(ExpectedResult, "tmp", "test");
>EXPECT_EQ(file->tryGetRealPathName(), ExpectedResult);  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-commits&data=02%7C01%7Cstilis%40microsoft.com%7Cc4e90b6970994d2b15b608d65eaf7ff3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636800505193880574&sdata=LRq7kLE%2BrPavTkQ2gSnc%2B%2FHrPMc8V1QQLWKr2gIPSBs%3D&reserved=0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: r348665 - [tests] Fix the FileManagerTest getVirtualFile test on Windows

2018-12-10 Thread Stella Stamenova via cfe-commits
The failure that you are getting when you run on the d:\ drive is what we were 
seeing before this change in our testing. What do you get without this change?

Thanks,
-Stella

-Original Message-
From: Aaron Ballman  
Sent: Monday, December 10, 2018 10:11 AM
To: Stella Stamenova 
Cc: cfe-commits 
Subject: Re: r348665 - [tests] Fix the FileManagerTest getVirtualFile test on 
Windows

On Mon, Dec 10, 2018 at 12:30 PM Stella Stamenova  wrote:
>
> Our tests run on drive E:\ (not C:\) which is why we saw this test failing. 
> After this change, the test can now run successfully for us because the 
> temporary files are created and checked for on the C:\ drive. Before this 
> change, the temporary files were created on the E:\ drive and checked for on 
> the C:\ drive.
>
> Are you saying that you have a drive C:\ and the test is failing anyway? Or 
> do you not even have a drive C:\?

I have two drives, C:\ and D:\. When I run this unit test (from my D drive), I 
now get:

[ RUN  ] FileManagerTest.getVirtualFileFillsRealPathName
D:\llvm\tools\clang\unittests\Basic\FileManagerTest.cpp(371): error:
Expected: file->tryGetRealPathName()
  Which is: { 'd' (100, 0x64), ':' (58, 0x3A), '/' (47, 0x2F), 't'
(116, 0x74), 'm' (109, 0x6D), 'p' (112, 0x70), '\\' (92, 0x5C), 't'
(116, 0x74), 'e' (101, 0x65), 's' (115, 0x73), 't' (116, 0x74) } To be equal 
to: ExpectedResult
  Which is: { 'C' (67, 0x43), ':' (58, 0x3A), '/' (47, 0x2F), 't'
(116, 0x74), 'm' (109, 0x6D), 'p' (112, 0x70), '\\' (92, 0x5C), 't'
(116, 0x74), 'e' (101, 0x65), 's' (115, 0x73), 't' (116, 0x74) } [  FAILED  ] 
FileManagerTest.getVirtualFileFillsRealPathName (2 ms)

I do not have a C:\temp or a D:\temp drive. If I move the test executable onto 
my C:\ drive, I get a different failure instead:

[ RUN  ] FileManagerTest.getVirtualFileFillsRealPathName
D:\llvm\tools\clang\unittests\Basic\FileManagerTest.cpp(371): error:
Expected: file->tryGetRealPathName()
  Which is: { 'c' (99, 0x63), ':' (58, 0x3A), '/' (47, 0x2F), 't'
(116, 0x74), 'm' (109, 0x6D), 'p' (112, 0x70), '\\' (92, 0x5C), 't'
(116, 0x74), 'e' (101, 0x65), 's' (115, 0x73), 't' (116, 0x74) } To be equal 
to: ExpectedResult
  Which is: { 'C' (67, 0x43), ':' (58, 0x3A), '/' (47, 0x2F), 't'
(116, 0x74), 'm' (109, 0x6D), 'p' (112, 0x70), '\\' (92, 0x5C), 't'
(116, 0x74), 'e' (101, 0x65), 's' (115, 0x73), 't' (116, 0x74) } [  FAILED  ] 
FileManagerTest.getVirtualFileFillsRealPathName (2 ms)

~Aaron

>
> Thanks,
> -Stella
>
> -Original Message-
> From: Aaron Ballman 
> Sent: Monday, December 10, 2018 6:55 AM
> To: Stella Stamenova 
> Cc: cfe-commits 
> Subject: Re: r348665 - [tests] Fix the FileManagerTest getVirtualFile 
> test on Windows
>
> On Fri, Dec 7, 2018 at 6:52 PM Stella Stamenova via cfe-commits 
>  wrote:
> >
> > Author: stella.stamenova
> > Date: Fri Dec  7 15:50:05 2018
> > New Revision: 348665
> >
> > URL:
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.
> > org%2Fviewvc%2Fllvm-project%3Frev%3D348665%26view%3Drev&data=02%
> > 7C
> > 01%7Cstilis%40microsoft.com%7Cc4e90b6970994d2b15b608d65eaf7ff3%7C72f
> > 98
> > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636800505193880574&sdata=v
> > v0
> > qe64wy0oqci7RAlCXHxmjREevqS3s%2ByNz83tqQIw%3D&reserved=0
> > Log:
> > [tests] Fix the FileManagerTest getVirtualFile test on Windows
> >
> > Summary: The test passes on Windows only when it is executed on the C: 
> > drive. If the build and tests run on a different drive, the test is 
> > currently failing.
> >
> > Reviewers: kadircet, asmith
> >
> > Subscribers: cfe-commits
> >
> > Differential Revision:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fre
> > vi
> > ews.llvm.org%2FD55451&data=02%7C01%7Cstilis%40microsoft.com%7Cc4
> > e9 
> > 0b6970994d2b15b608d65eaf7ff3%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> > 7C 
> > 0%7C636800505193880574&sdata=0dFS4XR2o85FyI0XHr9Eh4pX%2BbdC2CPhX
> > dd
> > X3lDYaao%3D&reserved=0
> >
> > Modified:
> > cfe/trunk/unittests/Basic/FileManagerTest.cpp
> >
> > Modified: cfe/trunk/unittests/Basic/FileManagerTest.cpp
> > URL:
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F

[clang] a9bef07 - [clang-format] Fix incorrect isspace input (NFC)

2022-06-29 Thread Stella Stamenova via cfe-commits

Author: Kevin Cadieux
Date: 2022-06-29T10:20:46-07:00
New Revision: a9bef0707db101bb72d000a1f09686d97fb2d35d

URL: 
https://github.com/llvm/llvm-project/commit/a9bef0707db101bb72d000a1f09686d97fb2d35d
DIFF: 
https://github.com/llvm/llvm-project/commit/a9bef0707db101bb72d000a1f09686d97fb2d35d.diff

LOG: [clang-format] Fix incorrect isspace input (NFC)

This change fixes a clang-format unit test failure introduced by 
[D124748](https://reviews.llvm.org/D124748). The `countLeadingWhitespace` 
function was calling `isspace` with values that could fall outside the valid 
input range. The valid input range for `isspace` is unsigned 0-255. Values 
outside this range produce undefined behavior, which on Windows manifests as an 
assertion being raised in the debug runtime libraries. `countLeadingWhitespace` 
was calling `isspace` with a signed char that could produce a negative value if 
the underlying byte's value was 128 or above, which can happen for non-ASCII 
encodings. The fix is to use `StringRef`'s `bytes_begin` and `bytes_end` 
iterators to read the values as unsigned chars instead.

This bug can be reproduced by building the `check-clang-unit` target with a 
DEBUG configuration under Windows. This change is already covered by existing 
unit tests.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D128786

Added: 


Modified: 
clang/lib/Format/FormatTokenLexer.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatTokenLexer.cpp 
b/clang/lib/Format/FormatTokenLexer.cpp
index 88b0d3b1970f7..66f03dcb53a12 100644
--- a/clang/lib/Format/FormatTokenLexer.cpp
+++ b/clang/lib/Format/FormatTokenLexer.cpp
@@ -864,8 +864,10 @@ static size_t countLeadingWhitespace(StringRef Text) {
   // Directly using the regex turned out to be slow. With the regex
   // version formatting all files in this directory took about 1.25
   // seconds. This version took about 0.5 seconds.
-  const char *Cur = Text.begin();
-  while (Cur < Text.end()) {
+  const unsigned char *const Begin = Text.bytes_begin();
+  const unsigned char *const End = Text.bytes_end();
+  const unsigned char *Cur = Begin;
+  while (Cur < End) {
 if (isspace(Cur[0])) {
   ++Cur;
 } else if (Cur[0] == '\\' && (Cur[1] == '\n' || Cur[1] == '\r')) {
@@ -874,20 +876,20 @@ static size_t countLeadingWhitespace(StringRef Text) {
   // The source has a null byte at the end. So the end of the entire input
   // isn't reached yet. Also the lexer doesn't break apart an escaped
   // newline.
-  assert(Text.end() - Cur >= 2);
+  assert(End - Cur >= 2);
   Cur += 2;
 } else if (Cur[0] == '?' && Cur[1] == '?' && Cur[2] == '/' &&
(Cur[3] == '\n' || Cur[3] == '\r')) {
   // Newlines can also be escaped by a '?' '?' '/' trigraph. By the way, 
the
   // characters are quoted individually in this comment because if we write
   // them together some compilers warn that we have a trigraph in the code.
-  assert(Text.end() - Cur >= 4);
+  assert(End - Cur >= 4);
   Cur += 4;
 } else {
   break;
 }
   }
-  return Cur - Text.begin();
+  return Cur - Begin;
 }
 
 FormatToken *FormatTokenLexer::getNextToken() {



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] c67656b - Revert "Allow searching for prebuilt implicit modules."

2020-11-05 Thread Stella Stamenova via cfe-commits

Author: Stella Stamenova
Date: 2020-11-05T17:16:14-08:00
New Revision: c67656b994c87224e0b33e2c4b09093986a5cfa6

URL: 
https://github.com/llvm/llvm-project/commit/c67656b994c87224e0b33e2c4b09093986a5cfa6
DIFF: 
https://github.com/llvm/llvm-project/commit/c67656b994c87224e0b33e2c4b09093986a5cfa6.diff

LOG: Revert "Allow searching for prebuilt implicit modules."

This reverts commit 71e108cd86e70b06c5fa3a63689dcb3555c3d13f.

This change caused a build failure on Windows:
http://lab.llvm.org:8011/#/builders/83/builds/570

Added: 


Modified: 
clang/docs/Modules.rst
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/CompilerInstance.h
clang/include/clang/Lex/HeaderSearch.h
clang/include/clang/Lex/HeaderSearchOptions.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Lex/HeaderSearch.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp

Removed: 
clang/test/Modules/Inputs/prebuilt-implicit-module/a.h
clang/test/Modules/Inputs/prebuilt-implicit-module/module.modulemap
clang/test/Modules/prebuilt-implicit-modules.m



diff  --git a/clang/docs/Modules.rst b/clang/docs/Modules.rst
index 703ba86c68a0..63f09f90fe6c 100644
--- a/clang/docs/Modules.rst
+++ b/clang/docs/Modules.rst
@@ -225,11 +225,6 @@ Command-line parameters
 ``-fprebuilt-module-path=``
   Specify the path to the prebuilt modules. If specified, we will look for 
modules in this directory for a given top-level module name. We don't need a 
module map for loading prebuilt modules in this directory and the compiler will 
not try to rebuild these modules. This can be specified multiple times.
 
-``-fprebuilt-implicit-modules``
-  Enable prebuilt implicit modules. If a prebuilt module is not found in the
-  prebuilt modules paths (specified via ``-fprebuilt-module-path``), we will
-  look for a matching implicit module in the prebuilt modules paths.
-
 -cc1 Options
 
 
@@ -240,123 +235,6 @@ Command-line parameters
   being built if the command line arguments are not homogeneous across your
   build.
 
-Using Prebuilt Modules
---
-
-Below are a few examples illustrating uses of prebuilt modules via the 
diff erent options.
-
-First, let's set up files for our examples.
-
-.. code-block:: c
-
-  /* A.h */
-  #ifdef ENABLE_A
-  void a() {}
-  #endif
-
-.. code-block:: c
-
-  /* B.h */
-  #include "A.h"
-
-.. code-block:: c
-
-  /* use.c */
-  #include "B.h"
-  void use() {
-  #ifdef ENABLE_A
-a();
-  #endif
-  }
-
-.. code-block:: c
-
-  /* module.modulemap */
-  module A {
-header "A.h"
-  }
-  module B {
-header "B.h"
-export *
-  }
-
-In the examples below, the compilation of ``use.c`` can be done without 
``-cc1``, but the commands used to prebuild the modules would need to be 
updated to take into account the default options passed to ``clang -cc1``. (See 
``clang use.c -v``)
-Note also that, since we use ``-cc1``, we specify the ``-fmodule-map-file=`` 
or ``-fimplicit-module-maps`` options explicitly. When using the clang driver, 
``-fimplicit-module-maps`` is implied by ``-fmodules``.
-
-First let us use an explicit mapping from modules to files.
-
-.. code-block:: sh
-
-  rm -rf prebuilt ; mkdir prebuilt
-  clang -cc1 -emit-module -o prebuilt/A.pcm -fmodules module.modulemap 
-fmodule-name=A
-  clang -cc1 -emit-module -o prebuilt/B.pcm -fmodules module.modulemap 
-fmodule-name=B -fmodule-file=A=prebuilt/A.pcm
-  clang -cc1 -emit-obj use.c -fmodules -fmodule-map-file=module.modulemap 
-fmodule-file=A=prebuilt/A.pcm -fmodule-file=B=prebuilt/B.pcm
-
-Instead of of specifying the mappings manually, it can be convenient to use 
the ``-fprebuilt-module-path`` option. Let's also use 
``-fimplicit-module-maps`` instead of manually pointing to our module map.
-
-.. code-block:: sh
-
-  rm -rf prebuilt; mkdir prebuilt
-  clang -cc1 -emit-module -o prebuilt/A.pcm -fmodules module.modulemap 
-fmodule-name=A
-  clang -cc1 -emit-module -o prebuilt/B.pcm -fmodules module.modulemap 
-fmodule-name=B -fprebuilt-module-path=prebuilt
-  clang -cc1 -emit-obj use.c -fmodules -fimplicit-module-maps 
-fprebuilt-module-path=prebuilt
-
-A trick to prebuild all modules required for our source file in one command is 
to generate implicit modules while using the ``-fdisable-module-hash`` option.
-
-.. code-block:: sh
-
-  rm -rf prebuilt ; mkdir prebuilt
-  clang -cc1 -emit-obj use.c -fmodules -fimplicit-module-maps 
-fmodules-cache-path=prebuilt -fdisable-module-hash
-  ls prebuilt/*.pcm
-  # prebuilt/A.pcm  prebuilt/B.pcm
-
-Note that with explicit or prebuilt modules, we are responsible for, and 
should be particularly careful about the compatibility of our modules.
-Using mismatching compilation options and modules may lead to issues.
-
-.. code-block:: sh
-
-  clang -c

[clang] ed98676 - Support multi-configuration generators correctly in several config files

2021-02-11 Thread Stella Stamenova via cfe-commits

Author: Stella Stamenova
Date: 2021-02-11T09:32:20-08:00
New Revision: ed98676fa4833bb80632fc7c9db10c3328d78485

URL: 
https://github.com/llvm/llvm-project/commit/ed98676fa4833bb80632fc7c9db10c3328d78485
DIFF: 
https://github.com/llvm/llvm-project/commit/ed98676fa4833bb80632fc7c9db10c3328d78485.diff

LOG: Support multi-configuration generators correctly in several config files

Multi-configuration generators (such as Visual Studio and Xcode) allow the 
specification of a build flavor at build time instead of config time, so the 
lit configuration files need to support that - and they do for the most part. 
There are several places that had one of two issues (or both!):

1) Paths had %(build_mode)s set up, but then not configured, resulting in 
values that would not work correctly e.g. 
D:/llvm-build/%(build_mode)s/bin/dsymutil.exe
2) Paths did not have %(build_mode)s set up, but instead contained 
$(Configuration) (which is the value for Visual Studio at configuration time, 
for Xcode they would have had the equivalent) e.g. 
"D:/llvm-build/$(Configuration)/lib".

This seems to indicate that we still have a lot of fragility in the 
configurations, but also that a number of these paths are never used (at least 
on Windows) since the errors appear to have been there a while.

This patch fixes the configurations and it has been tested with Ninja and 
Visual Studio to generate the correct paths. We should consider removing some 
of these settings altogether.

Reviewed By: JDevlieghere, mehdi_amini

Differential Revision: https://reviews.llvm.org/D96427

Added: 


Modified: 
clang/test/Unit/lit.site.cfg.py.in
lld/test/CMakeLists.txt
lld/test/Unit/lit.site.cfg.py.in
lld/test/lit.site.cfg.py.in
lldb/test/API/lit.site.cfg.py.in
llvm/cmake/modules/AddLLVM.cmake
llvm/test/CMakeLists.txt
llvm/test/Unit/lit.site.cfg.py.in
llvm/test/lit.site.cfg.py.in
mlir/examples/standalone/test/lit.site.cfg.py.in
mlir/integration_test/lit.site.cfg.py.in
mlir/test/Unit/lit.site.cfg.py.in
mlir/test/lit.site.cfg.py.in

Removed: 




diff  --git a/clang/test/Unit/lit.site.cfg.py.in 
b/clang/test/Unit/lit.site.cfg.py.in
index ad5e6d0c8b2a..3edab4473dc4 100644
--- a/clang/test/Unit/lit.site.cfg.py.in
+++ b/clang/test/Unit/lit.site.cfg.py.in
@@ -19,6 +19,7 @@ try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args

diff  --git a/lld/test/CMakeLists.txt b/lld/test/CMakeLists.txt
index ce0bcaa9203d..b2543901b757 100644
--- a/lld/test/CMakeLists.txt
+++ b/lld/test/CMakeLists.txt
@@ -1,8 +1,11 @@
-set(LLVM_SOURCE_DIR "${LLVM_MAIN_SRC_DIR}")
-set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
-set(LLVM_BUILD_MODE "%(build_mode)s")
-set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-set(LLVM_LIBS_DIR 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/%(build_config)s")
+if (CMAKE_CFG_INTDIR STREQUAL ".")
+  set(LLVM_BUILD_MODE ".")
+else ()
+  set(LLVM_BUILD_MODE "%(build_mode)s")
+endif ()
+
+string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLD_LIBS_DIR 
"${LLVM_LIBRARY_OUTPUT_INTDIR}")
+string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLD_TOOLS_DIR 
"${LLVM_RUNTIME_OUTPUT_INTDIR}")
 
 llvm_canonicalize_cmake_booleans(
   LLVM_ENABLE_ZLIB

diff  --git a/lld/test/Unit/lit.site.cfg.py.in 
b/lld/test/Unit/lit.site.cfg.py.in
index d96e20f11d0a..65d9f9d85935 100644
--- a/lld/test/Unit/lit.site.cfg.py.in
+++ b/lld/test/Unit/lit.site.cfg.py.in
@@ -8,8 +8,8 @@ config.llvm_build_mode = "@LLVM_BUILD_MODE@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.lld_obj_root = "@LLD_BINARY_DIR@"
 config.lld_src_root = "@LLD_SOURCE_DIR@"
-config.lld_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lld_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lld_libs_dir = "@LLD_LIBS_DIR@"
+config.lld_tools_dir = "@LLD_TOOLS_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.python_executable = "@Python3_EXECUTABLE@"
 
@@ -19,6 +19,8 @@ try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.lld_libs_dir = config.lld_libs_dir % lit_config.params
+config.lld_tools_dir = config.lld_tools_dir % lit_config.params
 except KeyError as e:
 key, = e.args
 lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % 
(key,key))

diff  --git a/lld/test/lit.site.cfg.py.in b/lld/test/lit.site.cfg.py.in
index a4e00b9dac93..a140284e0ded 100644
--- a/lld/test/lit.site.cfg.py.in
+++ b/lld/test/lit.site.cfg.py.in
@@ -9,8 +9,8 @@ config.llvm_tool

[clang] 734d688 - [clang] Fix a race condition in the build of clangInterpreter

2021-06-17 Thread Stella Stamenova via cfe-commits

Author: Stella Stamenova
Date: 2021-06-17T10:03:33-07:00
New Revision: 734d688fbce8a453aa61764b9b5a43b26455dc0d

URL: 
https://github.com/llvm/llvm-project/commit/734d688fbce8a453aa61764b9b5a43b26455dc0d
DIFF: 
https://github.com/llvm/llvm-project/commit/734d688fbce8a453aa61764b9b5a43b26455dc0d.diff

LOG: [clang] Fix a race condition in the build of clangInterpreter

The library depends on Attributes.inc, so it has to depend on the 
intrinsics_gen target

Reviewed By: v.g.vassilev

Differential Revision: https://reviews.llvm.org/D104311

Added: 


Modified: 
clang/lib/Interpreter/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Interpreter/CMakeLists.txt 
b/clang/lib/Interpreter/CMakeLists.txt
index e08779945b5fc..88a0a716e1269 100644
--- a/clang/lib/Interpreter/CMakeLists.txt
+++ b/clang/lib/Interpreter/CMakeLists.txt
@@ -12,6 +12,9 @@ add_clang_library(clangInterpreter
   IncrementalParser.cpp
   Interpreter.cpp
 
+  DEPENDS
+  intrinsics_gen
+
   LINK_LIBS
   clangAST
   clangAnalysis



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [EXTERNAL] [PATCH] D114639: Raise the minimum Visual Studio version to VS2019

2022-01-29 Thread Stella Stamenova via cfe-commits
I will take care of it today. The bot does have vs2019 installed and it should 
be picking up latest VS (and it was when I updated it), so there is an easy fix 
(remove 2017) and then I can investigate why it stopped picking up latest.

Get Outlook for iOS

From: Simon Pilgrim via Phabricator 
Sent: Saturday, January 29, 2022 3:12:52 AM
To: llvm-...@redking.me.uk ; Reid Kleckner 
; aaron.ball...@gmail.com ; 
ztur...@roblox.com ; jh7...@my.bristol.ac.uk 
; l...@meinersbur.de ; 
jan_svob...@apple.com ; greg_bedw...@sn.scee.net 
; Stella Stamenova 
Cc: jo...@devlieghere.com ; lldb-comm...@lists.llvm.org 
; h.vetin...@gmx.com ; 
vitalyb...@google.com ; jrhen...@gmail.com 
; reviews.llvm@jfbastien.com 
; erich.ke...@intel.com 
; joker@gmail.com ; Saleem 
Abdulrasool ; russell.gal...@sony.com 
; cfe-commits@lists.llvm.org 
; mgo...@gentoo.org ; 
mar...@martin.st ; llvm-comm...@lists.llvm.org 
; h.imai@nitech.jp ; 
bhuvanendra.kum...@amd.com ; gandhi21...@gmail.com 
; yanliang...@intel.com ; 
liburd1...@outlook.com ; serhiy.re...@gmail.com 
; quic_soura...@quicinc.com 
; dougp...@gmail.com ; 
david.spick...@linaro.org ; mlek...@skidmore.edu 
; blitzrak...@gmail.com ; 
shen...@google.com ; michael.hl...@gmail.com 
; bruce.mitche...@gmail.com 
; yuanfang.c...@sony.com 
Subject: [EXTERNAL] [PATCH] D114639: Raise the minimum Visual Studio version to 
VS2019

RKSimon added a comment.

@stella.stamenova It looks like the mlir-windows buildbot is still using VS2017:

  CMake Error at cmake/modules/CheckCompilerVersion.cmake:39 (message):
Host Visual Studio version must be at least 19.20, your version is
19.16.27045.0.

Are you able to make the fix or would you prefer I revert for now?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD114639%2Fnew%2F&data=04%7C01%7Cstilis%40microsoft.com%7C1299827a2cee41cb745b08d9e3184ba9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790515814400729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WccQ1%2B3T0IE2c%2BrjkWNmZIFZFsQaaGq6NIM8gpduOpY%3D&reserved=0

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD114639&data=04%7C01%7Cstilis%40microsoft.com%7C1299827a2cee41cb745b08d9e3184ba9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790515814400729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eymjF3kMlfwwx8%2Bf0B10dxYWaW%2BYkSuvmoWCCBuR2YE%3D&reserved=0

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits