I didn't update them because the build gives an error which does not matter for this release.

error: unexpected `cfg` condition value: `alloc`
   --> bitcoin/src/blockdata/transaction.rs:529:1
    |
529 | units::impl_parse_str_from_int_infallible!(Sequence, u32, from_consensus);

Yes, we need CI to pass for backport branches. Certainly we need my local CI to pass. Otherwise we are releasing untested stuff.

This is kind of fucked, we are going to have to start at the leaf crates and remove the doc_auto_cfg for as many versions as far back as we do releases. Then move up the stack - what an PITA.

EDIT: Oh, you worked that out already: #5084 (comment)

Bump.

You can ignore the clippy stuff I guess but the "invalid cfg" is a compiler error which I can't really override.

Aight, on it. Note to self remove auto_doc_cfg thing too.

EDIT: lol, this is literally what this PR is doing already.

I updated the lock files on top of the temporary hash and moved the changes into the patch before the temporary one, criky.

I think it's fine to keep this "hack" in place. Or we could just whitelist the lint. Your fix is incorrect though -- it deletes a call to impl_tryfrom_str_from_int_infallible which previously was called from within the macro, and therefore breaks the API. (I guess, your reason for the big "revert this" comment is that the hack affects bitcoin but not io? This seems unreasonably complicated. If we don't want to do a proper fix we should just whitelist the lint.)

Whatever you do, can you do it in the first commit of this PR rather than the last?

Answering from my memory because digging back through exactly which version of units is being used is bothersome. I believe that the code is buggy and the call to impl_tryfrom_str_from_int_infallible is not being called because the alloc feature does not exist in bitcoin. That's the reason I used <insert-normal-rant-about-calling-macros-across-crate-boundries>. But like I said I'd have to dig back through my branches to double check this.

I double-checked it and you are incorrect. There are two macro calls inside the macro and only one is alloc-gated.

But if we just whitelisted the lint we wouldn't need to think baout this.

Thanks, I'll do it.

In 4e8522a

Please just whitelist the lint. Add cfg(alloc) to the existing list of cfgs. Changing deny to warn does nothing for either Github's or my CI.

Add cfg(alloc) to the existing list

I tried that, it doesn't work. I don't know if I'm confused but its feature = "alloc" that is triggering the lint. I guess its something to do with how optional deps are treated as features so alloc is being misinterpreted as a dep (since there is no alloc feature in bitcoin then since there is no alloc dep the compiler goes on to say alloc is an unrecognized cfg. I tried various things before I switched the deny to warn.

Hmm, ok. Can you change deny to allow then?

"warn" is the same as "deny" in CI.

I actually tried this one and it appears to work.

Hmm, ok. Can you change deny to allow then?

Done

"warn" is the same as "deny" in CI.

For my understanding can you explain this? I was under the impression that I was making the build pass just so I could update the lock files. Do you mean that you have your CI box configured to fail for lint warnings. FTR I'm not super clear on why some lints are in the compiler and some in clippy.

Do you mean that you have your CI box configured to fail for lint warnings.

Yes. And we do the same in Github CI.

FTR I'm not super clear on why some lints are in the compiler and some in clippy.

It's more or less random.

This one is good to go @apoelstra, ack, merge, release - YOLO!

So, I'm failing to build this locally because we have hex-conservative 0.2.0 in the lockfile which has doc_auto_cfg. I think we need to release a hex-conservative 0.2.1 first.

Damn, I spat the dummy already earlier trying to get that done. (Its 0.2.2 we need I think, even though I was trying to do 0.2.1 earlier - ouch )

Oh I think the reason I'm having trouble is that there's no nightly-version file here. I think if we add this file with nightly-2024-09-15 (or whatever) that would let my local CI work despite the doc_auto_cfg mess.

OTOH fixing hex-conservative is probably the correct way to do this..

OTOH fixing hex-conservative is probably the correct way to do this..

You mean what you did already in rust-bitcoin/hex-conservative#197, right?

Yep. Released now. Can you update this PR to pull in hex-conservative 0.2.2? I think then we'll have no more doc_auto_cfg in bitcoin 0.32 or anything in its dep tree.

Thanks! Needs lockfile update.

Ping @tcharding

Reminder that tihs is blocking rust-bitcoin/rust-miniscript#805 ElementsProject/rust-elements#257 BlockstreamResearch/simplicity-webide#57 BlockstreamResearch/simplicity-webide#56 at least

Damn, this branch has what looks like all the lint warnings fixed in #5282. Are you ok to merge as is @apoelstra or do we want those fixed here too?

Nah. Maybe if we decide that we want to maintain io 0.1.x for real for some reason. But I don't think we do.

omfg now I have the doc_auto_cfg error in hashes 0.13.0.

Can we release a hashes 0.13.1?

Well, actually, io doesn't depend on hashes. Nothing depencd on hashes 0.13.0. It's just in the repo with io 0.1.x.

I think I should utACK and merge this.

BTW. The reason this is causing a crisis for us and not everybody is that it triggers specifically when we compile with the docsrs flag on, which we do in our local CI but is really not a normal thing to do.

Tagged and published.

Perhaps we should flesh out a script (or xshell) that does pre-release checks for PRs that have a title Release tracking PR: ... and in that do the docsrs build? (And check TBD and any other stuff we always forget.)

Yeah, that'd be nice. It'll be a PITA to do the docsrs build only for the crates that we're releasing, and not other crates which are broken..