Update llvm_versions
macro syntax to match Rust ranges
#493
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Refactor the
llvm_versions
internal macro implementation and update its syntax to more closely match normal Rust syntax.This means removing the
latest
special case in favor of half-open ranges (x..
) and allowing to specify up to x (..x
). This is also useful to have 2 different implementations of a function that changed at versiony
by having two items withllvm_version(..y)
andllvm_version(y..)
, just like when slicing a string or a vector.Since currently all supported versions are
<major>.0.0
, I've also allowed version specifiers to be just integers which represent just the major version.This refactoring is in preparation to add a new
cfg_attr
-style macro for conditional attributes, for exampledeprecated
, and to migrate remaining manual#[cfg(any(...))]
to this macro.The enum macro implementation is untouched, it was just moved to its own module.
How This Has Been Tested
Compiling a few selected LLVM versions.
Option<Breaking Changes>
Only to the
llvm_versions
internal macro.Checklist