This is an archive of the discontinued LLVM Phabricator instance.

[IR] Delete MODULE_CODE_DEPLIB
AbandonedPublic

Authored by MaskRay on Jan 25 2020, 4:51 PM.

Details

Reviewers
dexonsmith
void
Summary

In 2012 (rL168694), it was considered "never used and has bit-rotted".
Now is 2020.

Diff Detail

Event Timeline

MaskRay created this revision.Jan 25 2020, 4:51 PM

Unit tests: fail. 62194 tests passed, 1 failed and 815 were skipped.

failed: libc++.std/thread/thread_mutex/thread_mutex_requirements/thread_timedmutex_requirements/thread_timedmutex_recursive/try_lock_until.pass.cpp

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

mehdi_amini added inline comments.Jan 25 2020, 7:36 PM
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
3605

Isn't this breaking bitcode backward compatibility?

void added inline comments.Mar 29 2020, 7:46 PM
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
3605

This used to be okay when changing major versions. I'm not too familiar with the current versioning system though or whether that's still the policy.

mehdi_amini added inline comments.Mar 29 2020, 9:45 PM
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
3605

It changed when we changed the version numbering to not have major/minor anymore. At the time (IIRC) we considered we would break compatibility only if it is really motivated. The current section of the developer policy: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

MaskRay marked an inline comment as done.Apr 11 2020, 9:29 PM
MaskRay added inline comments.
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
3605

Is this a case that "really no one makes use of the feature"? It was planned to be removed in 4.0

mehdi_amini added inline comments.Apr 12 2020, 10:37 AM
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
3605

Anything that was "planned to be removed in 4.0" is now supported "forever" until we make an explicit choice to break backward compatibility.

The reason is that "4.0" was used during the development of the 3.x versions as "this future major breaking change version". At the time the major number was used to indicate the compatibility. When we reached 3.9 we decided to change the numbering, instead of going to 3.10 we went to 4.0 but after changing the meaning of the major number to not mean anything anymore with respect to bitcode backward compatibility.

dexonsmith requested changes to this revision.Jun 24 2020, 3:17 PM

Anything that was "planned to be removed in 4.0" is now supported "forever" until we make an explicit choice to break backward compatibility.

As Mehdi pointed out, the right fix is probably to update the comment(s) to something like:

// Deprecated, but still needed to read old bitcode files.
This revision now requires changes to proceed.Jun 24 2020, 3:17 PM
MaskRay abandoned this revision.Jun 24 2020, 6:24 PM