I checked the Developer Policy and Coding Standards but couldn't find anything about deprecation. If I were to replace a simple bit of syntax in TableGen, what would I say in the documentation? Was the old syntax "deprecated"; or the new syntax "preferred"; or the old syntax simply not documented?
Fine by me to say the old thing's deprecated.
Ideally, if it's not too painful - would be good if you could do a
complete migration to the new thing & remove the old thing, to help
keep things streamlined. (over multiple patches, with some
notification to llvm-dev and in release notes about the old thing
being deprecated and encouraging folks to move to the new thing ahead
of the removal of the old thing)
Oh my. You think I should patch every .td file in the system? That sounds a bit scary. I wrote a new test for range lists that tests the old and new range punctuator. And a release note is certainly in order. But I wasn't planning to patch all 600 .td files.
Oh my. You think I should patch every .td file in the system?
Potentially, yes. If it's worth changing, important to figure out the
long-term migration strategy/technical debt of having two ways of
doing things, etc.
If this is a pure .td feature that doesn't change the resulting output
- you could validate the change (maybe updating one .td at a time) by
diffing the output of tblgen given old/new .td syntax & show that they
produce exactly the same output.
That sounds a bit scary. I wrote a new test for range lists that tests the old and new range punctuator. And a release note is certainly in order. But I wasn't planning to patch all 600 .td files.
If it's not practical to automate (with sed, etc) and would be a very
long manual process (like 10s of hours) then - yeah, probably not
worth migrating everything up-front & just leave it as-is.
I think I could stomach changing the tests over time, although at least one should be left with the old punctuator. It's the "real" .td files that scare me.
Tell me more abut diffing the test files. I assume that the CHECK: lines are checking the important results of each .td file, and so if all the tests still pass, things are good. Are you suggesting some way of automating the comparison of the full outputs as part of the build, or just in my personal workspace?
I think I could stomach changing the tests over time, although at least one should be left with the old punctuator. It's the "real" .td files that scare me.
Yeah, I was mostly talking about the real .td files.
Tell me more abut diffing the test files.
Oh, sorry - I was mostly talking about diffing the real output of
llvm-tblgen given the production .td files.
I assume that the CHECK: lines are checking the important results of each .td file, and so if all the tests still pass, things are good. Are you suggesting some way of automating the comparison of the full outputs as part of the build, or just in my personal workspace?
I mean, sure - can do the same thing for the test files I guess. But
yeah, I meant diffing locally as a way to validate that your changes
to .td files had no effect in the results.
Oh yes, I am diffing the output of some of the tests in order to be sure everything is the same. And running the tests, too.
I have a question about the release notes. The current version of LLVM is 10. There are release notes for 12. What happened to poor old version 11?
Oh yes, I am diffing the output of some of the tests in order to be sure everything is the same. And running the tests, too.
I have a question about the release notes. The current version of LLVM is 10. There are release notes for 12. What happened to poor old version 11?
It's already branched for release - so patches committed to trunk
(unless they're cherrypicked to the 11 release branch) will be
released in 12.
Is it okay to edit the version 12 release notes, or is there a release maven to whom such changes should be sent?
Is it okay to edit the version 12 release notes,
Yep - just send patches for it like any other patch.
Oh yes, I am diffing the output of some of the tests in order to be sure everything is the same. And running the tests, too.
Don't just diff the tests -- diff the .inc files that are generated as
part of the real LLVM build. Or take hashes (shaXsum or whatever)
before and after. This really isn't too difficult to do, by the way:
find $builddir -name \*.inc -exec sha256sum {} \;
Do that before and after your change, and diff it -- you really should
be seeing zero changes for a frontend-only change to TableGen like
that.
Cheers,
Nicolai
Excellent idea, thanks.