search

correctcomputation / checkedc-clang

This is the primary development repository for 3C, a tool for automatically converting legacy C code to the Checked C extension of C, which aims to enforce spatial memory safety. This repository is a fork of Checked C's.
14 stars 5 forks source link

Delete 3C code that was used only by clangd3c? #610

Open mattmccutchen-cci opened 3 years ago

mattmccutchen-cci commented 3 years ago

The 3C core code (clang/include/clang/3C, clang/lib/3C) contains some code that was used only by clangd3c and will be unused as soon as microsoft/checkedc-clang#1052 is merged to our repository. (An example that came up during my investigation of #609 is ConstraintsInfo::ValidSourceFiles.) Should we delete this code so it doesn't get in the way of us making API changes, unless we have a specific reason to believe we will use certain parts of the code again in the future?

mwhicks1 commented 3 years ago

My inclination is to delete the dead code. However, if the code is something we'd be likely to bring back, in some form, if attempting to integrate our tools/process into an IDE, then maybe it's premature to delete? It really depends on what the code does. Much of what clang3c did before is not something we expect to have a tool do, IIRC.

mattmccutchen-cci commented 3 years ago

I'm not familiar with what clangd3c did, but my sense is that much of the code in question isn't how we'd want to design a new IDE integration even if the functionality is similar.

Rather than spending time trying to decide this up front, maybe a reasonable approach to take is: when you are working on a PR, if you would find it helpful to make an API change that would break clangd3c-specific code, then form your own opinion on whether we're better off removing the affected code, and if so, go ahead and remove it in your branch. But whether or not you initially removed the code, allow that decision to be changed as part of review of the PR. I suspect that most of the time, the decision will be "yes, remove it", but we can see.

I realize that once we actually merge the clangd3c removal, it may not be obvious whether a given piece of code was left dead by the clangd3c removal or by some other change. But either way, we would be weighing the potential future value of the code (for an IDE integration or some other foreseen purpose) against the cost of maintaining it.