The comment mentions deplibs should be removed in 4.0. Removing it in this patch.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
6,500 ms | x64 debian > libarcher.races::lock-unrelated.c |
Event Timeline
While I can appreciate the removal of deprecated functionality, I think that some sort of mention of this on llvm-dev at least 2 weeks prior to the removal is warranted. It impacts any downstream projects which may still be relying on a feature.
libcxxabi/test/test_demangle.pass.cpp | ||
---|---|---|
12418 | This should not be removed, its a name undecoration test case. |
Hi! Thanks for reviewing this revision. It's my first attempt to refactor the lib codebase. You are right and I wasn't aware the potential impact. I'll file email to llvm-dev and see if we can proceed this refactoring two weeks later.
Hi @compnerd , I've posted a thread (https://lists.llvm.org/pipermail/llvm-dev/2021-May/150690.html) at llvm-dev two weeks ago and received some positive feedbacks, could you please take another look and see if we can move forward?
Hi @lattner I wonder if you could review this patch given you support this on llvm-dev email list. Thanks in advance!
Given the thread on the mailing list, I think that this is fine as long as there is an accompanying test to validate the bitcode deserialization continues to work. Id wait a few days more to see if @dexonsmith has an opinion.
LGTM too (sorry for any delay; on vacation).
Note two historical quirks about this "Remove in 4.0" comment, which has experienced some bitrot.
- In the past, the community assumed that 4.0 would break compatibility with 3.x (like 3.0 did with 2.x). We since dropped that (and went from 3.9 to 4.0 without breaking compatibility), but I guess some of the boilerplate comments are still around. I think such comments in the bitcode parser were already removed since we don't anticipate breaking compatibility "ever".
- In the past, LLVM parsed (and auto-upgraded) old textual IR. At some point we dropped that requirement. We still parse some non-canonical forms of textual IR as a convenience (mainly to avoid having to update old testcases), but we're allowed to break compatibility when it "makes sense", unrelated to specific version numbers.
Thank everyone for the reviews and further clarification, I believe we reach an agreement this is ready to land. committing it now.
This should not be removed, its a name undecoration test case.