Page MenuHomePhabricator

smeenai (Shoaib Meenai)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 19 2016, 10:21 AM (130 w, 5 d)

Recent Activity

Today

smeenai updated the diff for D58317: [clang] Add install targets for library headers.

Update description

Wed, Feb 20, 5:19 PM · Restricted Project
smeenai updated the diff for D58317: [clang] Add install targets for library headers.

Switch to clang-library-headers pending cfe-dev discussion

Wed, Feb 20, 5:19 PM · Restricted Project
smeenai committed rG2d13dcacfb98: [clang] Add CMake target for installing clang's CMake exports (authored by smeenai).
[clang] Add CMake target for installing clang's CMake exports
Wed, Feb 20, 3:16 PM
smeenai committed rC354527: [clang] Add CMake target for installing clang's CMake exports.
[clang] Add CMake target for installing clang's CMake exports
Wed, Feb 20, 3:16 PM
smeenai committed rL354527: [clang] Add CMake target for installing clang's CMake exports.
[clang] Add CMake target for installing clang's CMake exports
Wed, Feb 20, 3:15 PM
smeenai closed D58480: [clang] Add CMake target for installing clang's CMake exports.
Wed, Feb 20, 3:15 PM · Restricted Project, Restricted Project
smeenai added a comment to D58317: [clang] Add install targets for library headers.

I'm not entirely happy with the name clang-dev-headers, and am open to suggestions. It's unfortunate clang-headers was already taken for something different, but renaming that target or increasing its scope seems bad for existing users. Other possibilities I thought of include clang-tooling-headers, though that might be confused with the headers for libTooling specifically, and clang-library-headers. I'm open to suggestions.

We could consider renaming clang-headers to e.g. clang-resource-headers and then reusing the name which would match llvm-headers. What do you think about that?

Wed, Feb 20, 3:14 PM · Restricted Project
smeenai committed rGdefb5a383b29: [clang] Switch to LLVM_ENABLE_IDE (authored by smeenai).
[clang] Switch to LLVM_ENABLE_IDE
Wed, Feb 20, 3:08 PM
smeenai committed rC354525: [clang] Switch to LLVM_ENABLE_IDE.
[clang] Switch to LLVM_ENABLE_IDE
Wed, Feb 20, 3:08 PM
smeenai committed rL354525: [clang] Switch to LLVM_ENABLE_IDE.
[clang] Switch to LLVM_ENABLE_IDE
Wed, Feb 20, 3:08 PM
smeenai closed D58284: [clang] Switch to LLVM_ENABLE_IDE.
Wed, Feb 20, 3:08 PM · Restricted Project, Restricted Project
smeenai created D58480: [clang] Add CMake target for installing clang's CMake exports.
Wed, Feb 20, 2:56 PM · Restricted Project, Restricted Project
smeenai retitled D58480: [clang] Add CMake target for installing clang's CMake exports from [clang] Add CMake target for clang's CMake exports to [clang] Add CMake target for installing clang's CMake exports.
Wed, Feb 20, 2:56 PM · Restricted Project, Restricted Project
smeenai added a comment to D58471: [CMake][runtimes] Set clang-header dependency for builtins.

Ah, I didn't realize there were existing uses of DEPS, but thanks for the rename :)

Wed, Feb 20, 2:44 PM · Restricted Project
smeenai accepted D58471: [CMake][runtimes] Set clang-header dependency for builtins.

LGTM

Wed, Feb 20, 1:45 PM · Restricted Project
smeenai added inline comments to D58415: Add Swift enumerator value for CodeView::SourceLanguage.
Wed, Feb 20, 12:48 PM · Restricted Project

Yesterday

smeenai added inline comments to D49587: [CMake] Support exporting runtimes using the CMake export.
Tue, Feb 19, 1:09 PM · Restricted Project, Restricted Project

Fri, Feb 15

smeenai created D58317: [clang] Add install targets for library headers.
Fri, Feb 15, 5:44 PM · Restricted Project
smeenai added a comment to D58317: [clang] Add install targets for library headers.

I'm not entirely happy with the name clang-dev-headers, and am open to suggestions. It's unfortunate clang-headers was already taken for something different, but renaming that target or increasing its scope seems bad for existing users. Other possibilities I thought of include clang-tooling-headers, though that might be confused with the headers for libTooling specifically, and clang-library-headers. I'm open to suggestions.

Fri, Feb 15, 5:44 PM · Restricted Project
smeenai accepted D58093: [CMake][runtimes] Use variables rather than ":" delimiters.

LGTM

Fri, Feb 15, 2:54 PM · Restricted Project
smeenai committed rGf59ea25ee62e: [docs] Document LLVM_ENABLE_IDE (authored by smeenai).
[docs] Document LLVM_ENABLE_IDE
Fri, Feb 15, 12:41 PM
smeenai committed rL354167: [docs] Document LLVM_ENABLE_IDE.
[docs] Document LLVM_ENABLE_IDE
Fri, Feb 15, 12:40 PM
smeenai closed D58286: [docs] Document LLVM_ENABLE_IDE.
Fri, Feb 15, 12:40 PM · Restricted Project
smeenai updated the diff for D58286: [docs] Document LLVM_ENABLE_IDE.

Comment

Fri, Feb 15, 12:38 PM · Restricted Project
smeenai added a comment to D58284: [clang] Switch to LLVM_ENABLE_IDE.

CC @lebedev.ri, since I believe you raised some issues during the corresponding LLVM change but those were addressed.

Yeah, i don't think i have any comments here.
The logic to pick the default of LLVM_ENABLE_IDE (based on the existence of CMAKE_CONFIGURATION_TYPES) seems hacky,
but it indeed does not currently detect QtCreator's CMake integration as "IDE", so i don't have any additional concerns,
this looks like a straight-forward cleanup.

What i do have concerns about, is that LLVM_ENABLE_IDE is not documented in https://llvm.org/docs/CMake.html

Fri, Feb 15, 8:40 AM · Restricted Project, Restricted Project
smeenai created D58286: [docs] Document LLVM_ENABLE_IDE.
Fri, Feb 15, 8:40 AM · Restricted Project
smeenai updated subscribers of D58284: [clang] Switch to LLVM_ENABLE_IDE.

CC @lebedev.ri, since I believe you raised some issues during the corresponding LLVM change but those were addressed.

Fri, Feb 15, 8:07 AM · Restricted Project, Restricted Project
smeenai created D58284: [clang] Switch to LLVM_ENABLE_IDE.
Fri, Feb 15, 8:06 AM · Restricted Project, Restricted Project
smeenai committed rGd705864074e6: [clang] Add build and install targets for clang libraries (authored by smeenai).
[clang] Add build and install targets for clang libraries
Fri, Feb 15, 8:00 AM
smeenai committed rGb4ff1abae264: [clang] Create install targets for non-shared libraries (authored by smeenai).
[clang] Create install targets for non-shared libraries
Fri, Feb 15, 8:00 AM
smeenai committed rL354141: [clang] Add build and install targets for clang libraries.
[clang] Add build and install targets for clang libraries
Fri, Feb 15, 8:00 AM
smeenai committed rL354140: [clang] Create install targets for non-shared libraries.
[clang] Create install targets for non-shared libraries
Fri, Feb 15, 8:00 AM
smeenai committed rC354141: [clang] Add build and install targets for clang libraries.
[clang] Add build and install targets for clang libraries
Fri, Feb 15, 7:59 AM
smeenai closed D58269: [clang] Add build and install targets for clang libraries.
Fri, Feb 15, 7:59 AM · Restricted Project
smeenai committed rC354140: [clang] Create install targets for non-shared libraries.
[clang] Create install targets for non-shared libraries
Fri, Feb 15, 7:59 AM
smeenai closed D58268: [clang] Create install targets for non-shared libraries.
Fri, Feb 15, 7:59 AM · Restricted Project

Thu, Feb 14

smeenai added a comment to D58269: [clang] Add build and install targets for clang libraries.

A couple of things I noticed while writing this patch:

Thu, Feb 14, 6:50 PM · Restricted Project
smeenai updated the diff for D58269: [clang] Add build and install targets for clang libraries.

Fix condition

Thu, Feb 14, 6:50 PM · Restricted Project
smeenai added a parent revision for D58269: [clang] Add build and install targets for clang libraries: D58268: [clang] Create install targets for non-shared libraries.
Thu, Feb 14, 6:44 PM · Restricted Project
smeenai added a child revision for D58268: [clang] Create install targets for non-shared libraries: D58269: [clang] Add build and install targets for clang libraries.
Thu, Feb 14, 6:44 PM · Restricted Project
smeenai created D58269: [clang] Add build and install targets for clang libraries.
Thu, Feb 14, 6:44 PM · Restricted Project
smeenai created D58268: [clang] Create install targets for non-shared libraries.
Thu, Feb 14, 6:41 PM · Restricted Project

Wed, Feb 13

smeenai accepted D58204: CMake: Fix stand-alone clang builds since r353268.

LGTM. There's more clean up that could be done here, but this addresses the immediate issue. Thanks!

Wed, Feb 13, 5:36 PM · Restricted Project, Restricted Project
smeenai accepted D58212: Explicitly enable clang-tools-extra for Fuchsia.

LGTM

Wed, Feb 13, 3:31 PM · Restricted Project
smeenai added a comment to D58204: CMake: Fix stand-alone clang builds since r353268.

This could also be improved by teaching clang to use LLVM_BUILD_MAIN_SRC_DIR when that's available.

Wed, Feb 13, 1:29 PM · Restricted Project, Restricted Project
smeenai added inline comments to D58204: CMake: Fix stand-alone clang builds since r353268.
Wed, Feb 13, 1:17 PM · Restricted Project, Restricted Project
smeenai added a comment to D58132: lld/elf: When demangling symbols, surround demangled symbol with quotes and include mangled symbol as well.
In D58132#1396724, @pcc wrote:

My personal opinion: 99% of the time I reckon users will want to see the demangled name (it's only us toolchain folks who might more often prefer the mangled names), and there's already a flag --no-demangle which can be used to suppress demangling if necessary. So I think I'd prefer making the COFF linker more like the ELF linker (i.e. don't show mangled names without a flag).

Wed, Feb 13, 11:49 AM · Restricted Project

Tue, Feb 12

smeenai added a comment to D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.
In D58157#1395716, @rnk wrote:

I think we have consensus, so I'll go ahead and stamp it. I don't see any zorg builders that this will affect, I think it will only affect developers... I guess just send a PSA to llvm-dev after you land it.

Tue, Feb 12, 11:11 PM · Restricted Project
Herald added a project to D49587: [CMake] Support exporting runtimes using the CMake export: Restricted Project.
Tue, Feb 12, 10:47 PM · Restricted Project, Restricted Project
Herald added a project to D57429: [docs] Document ignoring build directory: Restricted Project.

Ping.

Tue, Feb 12, 10:23 PM · Restricted Project
smeenai added inline comments to D58093: [CMake][runtimes] Use variables rather than ":" delimiters.
Tue, Feb 12, 4:41 PM · Restricted Project
smeenai updated subscribers of D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.

Can you also add clang-tools-extra to LLVM_ALL_PROJECTS?

Tue, Feb 12, 4:33 PM · Restricted Project
smeenai added a comment to D58132: lld/elf: When demangling symbols, surround demangled symbol with quotes and include mangled symbol as well.

It looks like always showing both mangled and demangled names makes the output a bit too large. I'm a little skeptical how useful it is. Where did you find it useful?

Tue, Feb 12, 4:27 PM · Restricted Project

Mon, Feb 11

smeenai committed rG9e624d54100b: [build] Remove a stray comment. NFC (authored by smeenai).
[build] Remove a stray comment. NFC
Mon, Feb 11, 6:25 PM
smeenai committed rL353793: [build] Remove a stray comment. NFC.
[build] Remove a stray comment. NFC
Mon, Feb 11, 6:25 PM
smeenai accepted D58092: [CMake] Don't override required compiler flags in the runtimes build.

LGTM

Mon, Feb 11, 6:07 PM · Restricted Project
smeenai accepted D58084: [CMake] Avoid passing -rtlib=compiler-rt when using compiler-rt.

I think the commit message could be clarified a bit. Something like

Mon, Feb 11, 5:29 PM · Restricted Project, Restricted Project
smeenai added a comment to D57987: lld: unquote possibly quoted `EXTERN("symbol")` entry in linker script.

I'll give @ruiu a bit to commit this, since he reviewed it, otherwise I can take care of that for you.

Mon, Feb 11, 11:55 AM · Restricted Project

Fri, Feb 8

smeenai added a comment to D57987: lld: unquote possibly quoted `EXTERN("symbol")` entry in linker script.

Do you need someone to commit this for you?

Fri, Feb 8, 7:20 PM · Restricted Project
smeenai added a reviewer for D57993: [CMake] Don't cache LLVM_MAIN_SRC_DIR: mgorny.

@mgorny mentioned a need for this to be cached in D57406#1376170, so I'll let him weigh in on this.

Fri, Feb 8, 7:16 PM · Restricted Project
smeenai accepted D57992: [CMake] Don't set <PROJECT>_STANDALONE_BUILD.

LGTM, thanks! I think this makes more sense than before.

Fri, Feb 8, 6:57 PM · Restricted Project, Restricted Project
smeenai added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Could we sanitize the list of LLVM_ENABLE_PROJECTS and error for unknown entries?

I'm fine with this. @smeenai are you doing this or would you like me to put up a patch for this?

Fri, Feb 8, 6:22 PM · Restricted Project
smeenai added a comment to D57775: [CMake] Support tests in runtimes layout.

@phosek and I discussed this on IRC, and I'm summarizing our discussion here. We're not sure if it actually makes sense for the runtimes build to set the *_STANDALONE_BUILD variables, and he was gonna play with that.

Fri, Feb 8, 5:52 PM
smeenai accepted D57776: [libcxx] Support runtimes and monorepo locations for tests.

LGTM

Fri, Feb 8, 5:46 PM · Restricted Project

Thu, Feb 7

smeenai committed rGbe9b65d89d39: [cmake] Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to NATIVE configure (authored by smeenai).
[cmake] Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to NATIVE configure
Thu, Feb 7, 1:00 PM
smeenai committed rL353463: [cmake] Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to NATIVE configure.
[cmake] Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to NATIVE configure
Thu, Feb 7, 1:00 PM
smeenai added a comment to rL353374: Bump minimum toolchain version.

This looks to have broken optimized tablegen builds with VS2015 even when the new switch is enabled. I'm guessing that option isn't passed into the cmake run for generating the optimized tablegen?

Thu, Feb 7, 1:00 PM

Wed, Feb 6

smeenai accepted D57873: [CMake] Mark runtime library link libraries as private.

LGTM

Wed, Feb 6, 9:55 PM · Restricted Project, Restricted Project
smeenai committed rG18f0bd78e2ce: [cmake] Drop clang-tools-extra from LLVM_ALL_PROJECTS (authored by smeenai).
[cmake] Drop clang-tools-extra from LLVM_ALL_PROJECTS
Wed, Feb 6, 5:14 PM
smeenai committed rL353354: [cmake] Drop clang-tools-extra from LLVM_ALL_PROJECTS.
[cmake] Drop clang-tools-extra from LLVM_ALL_PROJECTS
Wed, Feb 6, 5:13 PM
smeenai committed rG351314a14f70: [cmake] Add all subprojects to LLVM_ALL_PROJECTS (authored by smeenai).
[cmake] Add all subprojects to LLVM_ALL_PROJECTS
Wed, Feb 6, 1:52 PM
smeenai committed rL353346: [cmake] Add all subprojects to LLVM_ALL_PROJECTS.
[cmake] Add all subprojects to LLVM_ALL_PROJECTS
Wed, Feb 6, 1:49 PM
smeenai closed D57843: [cmake] Add all subprojects to LLVM_ALL_PROJECTS.
Wed, Feb 6, 1:49 PM · Restricted Project
smeenai added a comment to D57843: [cmake] Add all subprojects to LLVM_ALL_PROJECTS.

I'm putting this up for review just in case there's some potential for breakage I'm not seeing. Note that all these directories are present in the old monorepo as well, so it shouldn't break anyone who's still on that.

Wed, Feb 6, 1:20 PM · Restricted Project
smeenai updated subscribers of D57843: [cmake] Add all subprojects to LLVM_ALL_PROJECTS.
Wed, Feb 6, 1:20 PM · Restricted Project
smeenai created D57843: [cmake] Add all subprojects to LLVM_ALL_PROJECTS.
Wed, Feb 6, 1:18 PM · Restricted Project
smeenai committed rGaf8eadd94e7c: [cmake] Add openmp to LLVM_ALL_PROJECTS (authored by smeenai).
[cmake] Add openmp to LLVM_ALL_PROJECTS
Wed, Feb 6, 1:09 PM
smeenai added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..
In D57535#1387661, @lei wrote:

@delcypher I am having a problem with my internal build after this change have gone in. Can you please help to determine what went wrong? Previously I was able to do the following:

$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On '-DLLVM_ENABLE_PROJECTS=clang;llvm;compiler-rt;clang-tools-extra;openmp;lld' -DCMAKE_C_COMPILER=/home/llvm/gcc/7.3.0/bin/gcc -DCMAKE_CXX_COMPILER=/home/llvm/gcc/7.3.0/bin/g++ -DLLVM_BINUTILS_INCDIR=/usr/include $LLVM_SRC
$ ninja -j 20
$ ninja check-libomptarget check-openmp

After your patch, I get the following warning with the the cmake cmd:

CMake Warning:
  Manually-specified variables were not used by the project:
    LIBOMPTARGET_NVPTX_COMPUTE_CAPABILITIES
    LIBOMPTARGET_NVPTX_ENABLE_BCLIB
    OPENMP_ENABLE_LIBOMPTARGET

and:

$ ninja check-libomptarget check-openmp
ninja: error: unknown target 'check-libomptarget
Wed, Feb 6, 1:08 PM · Restricted Project
smeenai committed rL353343: [cmake] Add openmp to LLVM_ALL_PROJECTS.
[cmake] Add openmp to LLVM_ALL_PROJECTS
Wed, Feb 6, 1:08 PM

Tue, Feb 5

smeenai added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Ah, I just saw your llvm-dev posts. Thanks :)

Tue, Feb 5, 12:05 PM · Restricted Project
smeenai added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Do you have any follow-up plans here? No pressure; just didn't want to potentially duplicate any work.

I fixed the issue. Thanks for pointing it out.

Tue, Feb 5, 11:24 AM · Restricted Project

Mon, Feb 4

smeenai accepted D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Do you have any follow-up plans here? No pressure; just didn't want to potentially duplicate any work.

Mon, Feb 4, 1:32 PM · Restricted Project
smeenai added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Would it be equivalent if you changed https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/modules/AddLLVM.cmake;352949$1007-1009?as=source&blame=off from an option to a FORCEd cache set? The default value is computed based off the presence of the corresponding LLVM_EXTERNAL_*_SOURCE_DIR variable, which will be set for each project in LLVM_ENABLE_PROJECTS.

No it would not be equivalent.

In the case where the user is not using LLVM_ENABLE_PROJECTS, any user provided value for LLVM_TOOL_<PROJECT>_BUILD (e.g. LLVM_TOOL_CLANG_BUILD) would be ignored because it would always get overwritten with ${${canonical_full_name}_BUILD_DEFAULT}. This would break existing user workflows.

The whole point of this patch is to improve the LLVM_ENABLE_PROJECTS workflow without breaking workflows that set the LLVM_TOOL_<PROJECT>_BUILD variables. I'd like to stop LLVM_TOOL_<PROJECT>_BUILD variables from being CMake cache variables at some point so that those variables are no longer user facing. However that is going to require an RFC and is out of scope for this patch.

The branch in question is only taken when you haven't checked out the project in-tree, and I suspect most users of LLVM_TOOL_*_BUILD are using it for in-tree checkouts. Btw, that branch also checks for LLVM_EXTERNAL_*_BUILD variables, which you're also overriding in this patch, but I would hope no one was using those.

My preference would be to stop using the LLVM_TOOL_*_BUILD variables entirely for out-of-tree checkouts, and have that be completely controlled by LLVM_ENABLE_PROJECTS and LLVM_EXTERNAL_PROJECTS instead (which is effectively what this patch does for LLVM_ENABLE_PROJECTS, but in an indirect way). I think the LLVM_TOOL_*_BUILD variables still have value for in-tree checkouts (although with the impending monorepo migration, in-tree checkouts are probably not long for this world anyway, unless the read-only single project mirrors end up happening and then people check out those mirrors in-tree, for whatever reason).

I agree with all of the above but I think we need to communicate this clearly to other developers. My patch is indirect precisely because I want the support for setting the LLVM_TOOL_*_BUILD variables to still work when LLVM_ENABLE_PROJECTS is set.

Mon, Feb 4, 11:53 AM · Restricted Project

Sat, Feb 2

smeenai added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Would it be equivalent if you changed https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/modules/AddLLVM.cmake;352949$1007-1009?as=source&blame=off from an option to a FORCEd cache set? The default value is computed based off the presence of the corresponding LLVM_EXTERNAL_*_SOURCE_DIR variable, which will be set for each project in LLVM_ENABLE_PROJECTS.

No it would not be equivalent.

In the case where the user is not using LLVM_ENABLE_PROJECTS, any user provided value for LLVM_TOOL_<PROJECT>_BUILD (e.g. LLVM_TOOL_CLANG_BUILD) would be ignored because it would always get overwritten with ${${canonical_full_name}_BUILD_DEFAULT}. This would break existing user workflows.

The whole point of this patch is to improve the LLVM_ENABLE_PROJECTS workflow without breaking workflows that set the LLVM_TOOL_<PROJECT>_BUILD variables. I'd like to stop LLVM_TOOL_<PROJECT>_BUILD variables from being CMake cache variables at some point so that those variables are no longer user facing. However that is going to require an RFC and is out of scope for this patch.

Sat, Feb 2, 11:04 AM · Restricted Project

Fri, Feb 1

smeenai added a reviewer for D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg: mgrang.
Fri, Feb 1, 8:15 PM · Restricted Project, Restricted Project
smeenai added reviewers for D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg: rnk, efriedma.

+@hans for the release branch.

Fri, Feb 1, 8:15 PM · Restricted Project, Restricted Project
smeenai added reviewers for D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used.: phosek, smeenai.

Would it be equivalent if you changed https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/modules/AddLLVM.cmake;352949$1007-1009?as=source&blame=off from an option to a FORCEd cache set? The default value is computed based off the presence of the corresponding LLVM_EXTERNAL_*_SOURCE_DIR variable, which will be set for each project in LLVM_ENABLE_PROJECTS.

Fri, Feb 1, 7:20 PM · Restricted Project
smeenai added inline comments to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..
Fri, Feb 1, 7:12 PM · Restricted Project

Thu, Jan 31

smeenai committed rL352790: [cmake] Note future cleanup in comment. NFC.
[cmake] Note future cleanup in comment. NFC
Thu, Jan 31, 12:32 PM
smeenai added inline comments to D57533: lit: support long paths on Windows.
Thu, Jan 31, 12:21 PM · Restricted Project
smeenai added a comment to D57533: lit: support long paths on Windows.

Wait, what happens if you call shutil.rmtree with the \\?\ normalized path, instead of dropping down to ctypes?

Thu, Jan 31, 12:09 PM · Restricted Project
smeenai added inline comments to D57533: lit: support long paths on Windows.
Thu, Jan 31, 12:07 PM · Restricted Project

Tue, Jan 29

smeenai added inline comments to D57429: [docs] Document ignoring build directory.
Tue, Jan 29, 5:25 PM · Restricted Project
smeenai added a comment to D57429: [docs] Document ignoring build directory.

An alternative would be to just add build to our top-level .gitignore, assuming that's what most people are naming their build directory. @pcc attempted to do something a bit more ambitious in D57400, but just ignoring /build* (as suggested by @jyknight there) shouldn't cause issues, I think.

Tue, Jan 29, 5:24 PM · Restricted Project
smeenai created D57429: [docs] Document ignoring build directory.
Tue, Jan 29, 5:22 PM · Restricted Project
smeenai added a comment to D57063: [CMake] Unify scripts for generating VCS headers.

Still LGTM.

Tue, Jan 29, 2:47 PM · Restricted Project
smeenai added a comment to D57330: Adjust documentation for git migration..

You can avoid the git status pollution by adding the build directory to .git/info/exclude.

Good to know! Should we include this in the doc?

Tue, Jan 29, 2:19 PM
smeenai committed rL352550: [docs] Prevent O0 optnone for opt input.
[docs] Prevent O0 optnone for opt input
Tue, Jan 29, 2:17 PM
smeenai closed D56950: [docs] Prevent O0 optnone for opt input.
Tue, Jan 29, 2:17 PM
smeenai added a comment to D56950: [docs] Prevent O0 optnone for opt input.

I might just commit for post-commit review, since @craig.topper weighed in on my main question above.

Tue, Jan 29, 2:15 PM