Better type deprecation messages#97114
Conversation
5926a80 to
0ec301b
Compare
|
👍 for removing I'm not sure about the message: |
Not sure what you mean. |
|
@infinisil I meant that the implementation of It was actually cole-h that noticed this in #96042
|
|
@rnhmjoj I guess that's just because only a subset of |
Previously the only way to deprecate a type was using theType = lib.warn "deprecated" (mkOptionType ...) This caused the warning to be emitted when the type was evaluated, but the error didn't include which option actually used that type. With this commit, types can specify a deprecationMessage, which when non-null, is printed along with the option that uses the type
Has been deprecated since fd803fc (2013-08-22)
0ec301b to
a582f6a
Compare
|
I updated it to also print the files where the option is defined. |
Motivation for this change
We want to deprecate option types over time, but how it's currently done, it's very hard to figure out which options actually use these deprecated types. This PR improves on this by allowing types to set a
deprecationMessage, which when set, is displayed along the option that uses the type.So with an option using
types.loaOf, you now getSimilar for
types.stringandtypes.optionSet. I also removedtypes.listcompletely because it's been deprecated for 7 years.Previous PR's/commits that deprecated option types: fd803fc, #54637, #66346 (#16750), #96042 (#1800, #63103, #77189)
I also plan to deprecate more types in the future.
Ping @roberth @rycee @Profpatsch @danbst @rnhmjoj @worldofpeace @cole-h
Things done