May 27 2019
May 21 2019
Apr 16 2019
That makes sense 👍
This will be nice to prevent bugs in the future. Should it be behind #ifndef NDEBUG though? Presumably if assertions are disabled then this bug would be expected to be undefined behavior and avoid the overhead of the thread local variable, is that right?
I tested this and confirm that it solves the bug (which I reported).
Feb 13 2019
I confirm this solves the issue.
Feb 1 2019
Thanks Hans. I'll need you to do it on my behalf as I do not have commit privileges.
Jan 4 2019
Is the problem that it is a SubroutineType, but not a function *pointer*?
Generally, if the Verifier accepts it we ought to not crash, so this seems to be okay, but it might be worth asking whether this is really what you want your frontend to be creating since subroutinetypes don't have a size, etc.
Dec 30 2018
In that case, you might want to add the DINode::FlagStaticMember flag to all your methods. If a DISubprogram lists a DICompositeType as its scope or is used as an element of the composite type, it gets treated as a C++-style method where the first argument is assumed to be 'this'. That's a very C++-centric way to do things, so it might be nicer if we explicitly marked C++ instance methods, but that's the way things are today and changing it would require thinking about backwards compatibility. >_>
The benefit of explicitly marking everything as a "static" method for zig is that if the first argument happens to be a pointer type it won't end up looking like an instance method.
Dec 26 2018
We can change the code to avoid the crash, but what debug info did you want clang to emit? It seems like the best way to describe StructWithNoFields_add is as a static method of the class StructWithNoFields, since it doesn't appear to have a 'this' parameter.
Dec 23 2018
I think this patch broke Zig's tests:
Dec 4 2018
Added Rui's test case. Thank you for helping me with that. Please note that I do not have commit privileges and so someone will have to merge this on my behalf.
Aug 27 2018
What is this change actually solving? Even if the typedef is actually redundant, it shouldn't cause a compiler error: redundant typedefs are allowed in the latest versions of the C and C++ standards. (And even if you were targeting an earlier standard, we normally suppress warnings in system headers.)
Aug 25 2018
Addressed review feedback
Aug 22 2018
Jul 26 2018
Thanks. Can you do the commit? I do not have commit access.
Jul 9 2018
Jun 15 2018
Ping. Is it time yet? Looks like the stated blockers are resolved now.
Apr 11 2018
I confirm that this fixes https://bugs.llvm.org/show_bug.cgi?id=36991
Mar 30 2018
Mar 2 2018
Would llvm interact with grow_memory or memory_size instructions? Seems like that would be the frontend or standard library's job. It's not in LLVM's business to interact with the "OS" by allocating memory.
Is there anything stopping this from landing in svn?
Feb 19 2018
Never mind these changes. I've redesigned how coroutines will work in Zig and they no longer depend on these changes.
Feb 15 2018
Feb 12 2018
Jan 16 2018
Hans, thank you for reviewing. I do not have commit access; would you mind committing it for me, in whatever order you prefer?
Jan 11 2018
Jan 9 2018
Jan 8 2018
I would have selected a repository but the instructions explicitly say not to:
Leave the Repository field blank.
Jan 6 2018
I'll be careful next time, thanks. I used the web interface. Arcanist seemed more involved, but if that is preferable I can do it next time.
Thank you, I will CC llvm-commits next time. I followed these instructions: https://llvm.org/docs/Phabricator.html
I would also like to request that this is backported to the release_60 branch.
Nov 2 2017
Which we prefer, maximum IO performance or a reliable error handling?
Oct 23 2017
Aug 18 2017
- Can we have this even without tests?
- Can we have this in 5.0.0?