Sat, Aug 10
Tue, Aug 6
Thank you for taking the time to fix this properly, Modules+LTO linked successfully.
Sun, Aug 4
Jul 9 2019
Jun 4 2019
As trivial as it may seem, this is missing tests, even if it's for a few flags. Also please try to include context with your patches as it makes them much easier to review. If you have some sort of plan for actually bringing Mach-O LLD closer to ld64 feature-wise, I think llvm-dev may be a good place to actually outline your plan for this, which will give everyone a more clear picture of what future changes you have planned in mind.
Experienced the same, updated my test build configuration to always force CLANG_ENABLE_STATIC_ANALYZER to On when building with tests. Maybe it's worth adding a warning about when Clang tests are being built?
May 28 2019
Would it make sense to also add a test explicitly using llvm::hash_combine
Using llvm::hash_combine on what, exactly?
as well as a negative test where hash code comparison fails for a literal and the same literal in a StringRef every time
You mean something like ASSERT_NE(SymName1.data(), SymName2.data());?
May 25 2019
I have a question about qsort.. If we provide own implementation of qsort and replace calls to libc's qsort to our qsort, we could fully inline cmp function then. Ideas?
Seems good. Would it make sense to also add a test explicitly using llvm::hash_combine, as well as a negative test where hash code comparison fails for a literal and the same literal in a StringRef every time (if it's possible to do reliably)? Just a random suggestion, probably overly paranoid.
May 16 2019
My bad, I didn't check well enough, it seems an unrelated patch made certain tests crash due to asserts. Thanks to @craig.topper for pointing that out.
This seems to be causing multiple performance regressions across several bots in compile time and execution time tests.
Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.
May 15 2019
Reverted in rL360842 as Windows bots were failing.
Landing this as discussed on IRC, will try to push it forward with WG14.
May 10 2019
Need @rsmith to bless this as it's introducing a nonstandard extension, however small it may be. The original diff did have a consensus on it, so I didn't really put up a formal RFC on cfe-dev.
Actually I got it wrong, the path is normalized to use regular slashes at that point, so there is no point in handling backslashes in paths at all even with Microsoft extensions.
May 9 2019
Fix style, remove unnecessary braces, add missing newline.
Superseded by D61756
May 8 2019
Sorry, forgot about this, will make a new diff with just the macro for review later tonight.
Apr 9 2019
Apr 5 2019
Mar 12 2019
I did, there are no references to any PassManager related material in the first three chapters.
Please make sure to specify Differential Revision: https://reviews.llvm.org/D59243 with Dxxxxx being the differential number in the URL when committing (on a separate line in the commit message) which will autmatically close the differential and link it to the commit which makes sure there are no stray/stale differentials. Alternatively manually link the diff to the commit (you can do that by simply quoting the commit as rL<SVN Rev> and then closing the differential manually.
Mar 11 2019
Mar 3 2019
Feb 28 2019
If the author is still missing at the end of next week, any objections to me resubmitting a similar patch that just implements __FILE_NAME__ or __BASE_NAME__ (Need a few more opinions here I guess, personally I think __FILE_NAME__ makes more sense)?
Feb 27 2019
Gentle ping for author, has this landed or still in the backlog? (If it's landed can you attach the commit and close it, please? Just trying to to avoid diffs on Phab going stale.)
What about using /*/ at the ignore pattern? This allows top-level files, and makes only new top-level *directories* require an ignore update. To my mind, that seems a bit more narrowly scoped and might be a bit less surprising. Thoughts?
Feb 26 2019
Feb 25 2019
@RalfJung Do you need someone to commit this? I can do it if you'd like.
Please make sure you have llvm-commits added as a subscriber when creating patches in the future (I'm not sure why Herald sometimes doesn't do it). The patch that changed this was rL322965, and I fixed one of the related regressions, and was meaning to update the docs but never did, so LGTM and I'm happy signing off on this.
Feb 24 2019
Feb 16 2019
I still don't like it...It's different, unusual, and IMO surprising to have such a wildcard ignore.
We haven't tended to have lots of random accidental file additions before, and while someone may surely mess up again, I don't think it likely to be a common occurrence.
I'd much prefer simply the targeted ignore of "/build*", at least for starters.
I'm in favor of this and I agree with @pcc's points and reasoning behind this.
Feb 15 2019
I actually like the D57400 approach more, it's much easier to keep a list of known top level projects as a whitelist. There are many names people could give to such a build directory (out or build or b) not to mention any other cruft one may have there. (ie. I build a libc as part of toolchain build).
Feb 6 2019
The patch itself looks sound. However given that you have a specific use case in mind (TableGen files) could you provide supplementary coverage for that specific use case (unit tests for formatting td syntax using format::getLLVMStyle(format::FormatStyle::LK_TableGen)? I'm not entirely sure how useful this particular change is given that there's no linked patches related to your use case, I think adding those would help as well (possibly as a separate dependent patchset).
Jan 29 2019
FWIW, this also broke my bootstraps of mingw-w64 environments/toolchains. After building compiler-rt builtins, before having any libunwind/libcxx built, I previously regarded my toolchain as complete for building and testing C apps and libraries, but that fails now.
Would it be possible to add a third alternative, --unwindlib=none, to signal that while I'm using --rtlib=compiler-rt, I don't want to link to any unwinder? (In my case, I'm injecting libunwind in libc++.a so it only gets added when linking C++ code.) Or at least make it possible to only add this linker flag when linking C++? Alternatively I'll need to provide a dummy libunwind.a until the real one has been built.
Jan 28 2019
One more thing, shouldn't libunwind be only included for C++ (since it's the internal dependency of libc++abi)? There shouldn't be any need to include it for C.