In 2012 (rL168694), it was considered "never used and has bit-rotted".
Now is 2020.
Details
- Reviewers
dexonsmith void
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
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.
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3605 | Isn't this breaking bitcode backward compatibility? |
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. |
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 |
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 |
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. |
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.
Isn't this breaking bitcode backward compatibility?