-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve deprecation of old enums #4944
Conversation
Recent GCC enables `-Wunused-const-variables`, which makes output quite noisy. Disable unused warnings for our deprecated variables.
The C standard does not specify whether an enum is a signed or unsigned type. Obviously, any enum that includes negative values _must_ be signed, but if all values are positive then the compiler is free to choose signed or unsigned. Thus, by changing the type signatures to `git_object_t` and declaring the old `GIT_OBJ_` values as a signed or unsigned int, we risk a mismatch between what the compiler has chosen for a `git_object_t`'s type and our type declaration. Thus, we declare the deprecated values as the enum instead of guessing.
Note that I'm still a little bit on the fence about how we're deprecating these; I think that it might make sense to just keep them as |
Yeah, I think keeping them as I don't think it's going to matter when we deprecate things: at some point in time, users will most likely be annoyed by the warnings. I'm rather pessimistic that anybody will actually update his code as long as they are not explicitly being marked as deprecated to emit warnings. Not saying this is due to lazyness, but more due to discoverability. I wouldn't think that every downstream user reads our release notes. |
AFAICT, no, it's not. Certainly not on all compilers, but maybe you could do some epic hackery to do something.
I agree. My counterpoint, though, is, do we ever really need to remove these for anything other than our own clutter? We could create This has the advantage of us being able to use |
What I mentioned up there (the |
I'm fine with a |
Are My POV is that, it depends on the amount of fixing needed by the deprecation. Things like |
My question is: why remove them at all? |
On Mon, Jan 21, 2019 at 07:49:16AM -0800, Edward Thomson wrote:
My question is: why remove them at all?
I'd always vote to remove deprecated things that are expected to
be a maintenance burden in the long run. But all the deprecations
we have done now (git_buf_free, git_objtype, giterr) are quite
trivial and I don't expect us to touch them again in the near- or
mid-term future.
As long as we move away the old declarations to decrease their
visibility like @ethomson proposed with the "deprecated.h"
header, I would be fine with keeping them for a long time.
|
Add
__attribute__((used))
to theGIT_DEPRECATED
macro, otherwise this will be seen as an "unused const variable".Also, use the enum type in the declaration of deprecated values. The C standard does not specify whether an enum is a signed or unsigned type. Obviously, any enum that includes negative values must be signed, but if all values are positive then the compiler is free to choose signed or unsigned.
Thus, we declare the deprecated values as the enum instead of guessing.