mstorsjo wrote:
> > a number of test input files need to be in LF form to work
>
> Which ones?
A whole bunch of them. @AaronBallman's link to
https://buildkite.com/llvm-project/github-pull-requests/builds/65#0192a01b-d3ac-44ad-abff-e53ac4a206ab
shows mostly what I saw. If including `clang
mstorsjo wrote:
> This seems to have broken precommit CI on Windows:
> https://buildkite.com/llvm-project/github-pull-requests/builds/65#0192a01b-d3ac-44ad-abff-e53ac4a206ab
> all of the failures look related to line endings, and I noticed that I got a
> ton of command line messages of the
mstorsjo wrote:
This causes lots of build time warnings when building with GCC, like this:
```
[271/4090] Building CXX object lib/Obj...akeFiles/LLVMObject.dir/Minidump.cpp.o
In file included from ../include/llvm/Object/Minidump.h:16,
from ../lib/Object/Minidump.cpp:9:
../include
mstorsjo wrote:
> The amount of churn is already pretty high -- please make sure the original
> commit, fixes, and reverts get added to
> https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs. At the
> end of the day, we have a number of tests and files which are sensitive to
mstorsjo wrote:
> > > It's my understanding that text=auto does not override core.autocrlf. As
> > > far as I can tell from the documentation it honours the user's
> > > configuration for core.eol in combination with core.autocrlf - from git
> > > config --help:
>
> > This doesn't match my ex
mstorsjo wrote:
> So if I've read that correctly, `core.autocrlf=false` is a red herring and
> you should really set `core.eol=lf` if you want git to use `lf` on windows.
That perhaps may be the case, but all common docs and all common practices
around this revolve around setting `core.autocrl
mstorsjo wrote:
> This patch is about respecting local config, which is the exact opposite of
> that suggestion. It would be a way to solve the line-ending issue by fiat,
> not by co-operation, so I'm against it on principle. To be clear I very much
> don't like CRLF, but I also very much don'
mstorsjo wrote:
> I think this is due to a subtly of config. Setting `core.autocrlf` to `false`
> doesn't actually do anything since it's the default.
In Git for Windows, the default actually is `core.autocrlf` set to `true`. When
manually installing, the installer wizard used to ask the user
mstorsjo wrote:
> > if all tests would have been cleaned up before this
>
> That was most certainly my intention, and I saw green before merging, so I
> must've looked in the wrong place
Ah, right - as we've seen that the CI runner normally only updates an existing
checkout, where changes to
mstorsjo wrote:
> I must have missed this PR originally. I oppose letting Git change any line
> endings. It always ends like this.
Also just for context - the Clang precommit CI is allegedly still broken,
because those buildbots happened to be restarted when we had these
gitattributes in plac
mstorsjo wrote:
> Remove `SymbolFilePDB` in favor of always using `SymbolFileNativePDB`. This
> effectively makes `LLDB_USE_NATIVE_PDB_READER` the default. The non-native
> (DIA based) PDB symbol file implementation was unmaintained and known to have
> issues.
While this certainly is true, un
mstorsjo wrote:
> Interesting. Based on a conversation at the dev meeting, I was under the
> impression that the DIA-based implementation was in worse shape and the
> native one in better shape. I also have a memory of bug reports about PDB
> parsing where originators were asked to check with
https://github.com/mstorsjo approved this pull request.
LGTM, this seems reasonable - I guess the new form should match both
`breakpoint 1` and `breakpoint 1.1`.
https://github.com/llvm/llvm-project/pull/115318
___
lldb-commits mailing list
lldb-commi
mstorsjo wrote:
FYI, this had a small impact on deployability on macOS; I used to build LLVM
with 10.9 as a deployment target, but now get these errors:
```
/Users/runner/work/llvm-mingw/llvm-mingw/llvm-project/lldb/include/lldb/Target/StackFrameList.h:161:16:
error: 'shared_mutex' is unavaila
mstorsjo wrote:
> When we decided to allow C++11 usage in lldb I think we opted into requiring
> platforms that have relatively complete support for the C++11 additions. I
> don't think it makes sense to try to limit the use of C++11 to some "minimal
> supported subset".
Yeah, I don’t disagre
mstorsjo wrote:
> Thanks, for the report, will be fixed by #132551
Thanks for the quick fix, I can confirm that Qt builds fine for me again!
https://github.com/llvm/llvm-project/pull/132401
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
Author: Martin Storsjö
Date: 2025-04-05T16:55:36+03:00
New Revision: fcead25550bb727215919ecf2dfad17765223c19
URL:
https://github.com/llvm/llvm-project/commit/fcead25550bb727215919ecf2dfad17765223c19
DIFF:
https://github.com/llvm/llvm-project/commit/fcead25550bb727215919ecf2dfad17765223c19.diff
mstorsjo wrote:
> Closing this since Docker on macOS simply disabled SME, SVE, etc. I believe
> this is still an issue in theory for users with Linux installed directly on
> M4 hardware but if such a user exists I haven't heard of them.
Wouldn't this still be an issue if running virtualized Li
mstorsjo wrote:
> For the record, this PR was finally re-landed as #126988 after four separate
> commits to address issues found in CI testing when I originally merged this.
FWIW, it looks like my smoke tests are still passing fine after these changes
have been relanded now:
https://github.co
mstorsjo wrote:
This change broke building Qt (tested with 6.8), ending up with errors like
this:
```
qtbase/src/corelib/kernel/qcoreapplication.cpp:2946:78: error: 'this' cannot be
used in a static member function declaration
2946 | : slotObject(std::move(slotObject)), context(co
https://github.com/mstorsjo approved this pull request.
LGTM, thanks! I can confirm that this fixes compilation on mingw targets, on
both 32 and 64 bit.
https://github.com/llvm/llvm-project/pull/139711
___
lldb-commits mailing list
lldb-commits@lists.
mstorsjo wrote:
Hi Pavel!
Unfortunately, it seems like this change has broken compilation of LLDB for
mingw, on all architectures. With MSVC and clang-cl, it is broken for 32 bit
platforms, while the issue only shows up as a warning for 64 bit architectures
there.
On 64 bit mingw:
```
llvm-p
mstorsjo wrote:
> > Therefore, this situation should only be an issue with older kernels, so
> > perhaps it not something that regular user mode applications should need to
> > worry about (unless specifically wanting to run with older kernels).
>
> I will test this PR with an older kernel as
https://github.com/mstorsjo approved this pull request.
LGTM
IIRC @petrhosek had commented on this before, and was generally in favour of
it, but I'd still leave it open for a couple days if he wants to comment
further on it.
https://github.com/llvm/llvm-project/pull/138587
__
mstorsjo wrote:
> I rebased this on top of #138783 and adjusted the title and description. Now
> it should be in a good state to push cmake changes for other projects.
The changes look good, but it looks like the changes from #138783 still show up
when viewing the changes; can you check that y
mstorsjo wrote:
> truncate the section names, as [sections in PE/COFF executable images can't
> be longer than 8
> bytes](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers).
First off, this probably meant to say "section names can't be longer than 8
101 - 126 of 126 matches
Mail list logo
