Deprecate __int128, __uint128, __int128_t, __uint128

[sanstzu]

Description

Deprecates __int128, __uint128, __int128_t, __uint128_t and replace them with u128/i128 types, as per (#4340)

Sources

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in the Android module

cc @maurer

[tgross35]

Could you set the version to 0.2.172? We can backport the deprecation, 1.0 will just have the removal. You can also add back the changes to use i128/u128 internally, that is a non-breaking change.

Those two things and a squash, then lgtm!

@rustbot label +stable-nominated

[sanstzu]

Could you set the version to 0.2.172? We can backport the deprecation, 1.0 will just have the removal. You can also add back the changes to use i128/u128 internally, that is a non-breaking change.

Those two things and a squash, then lgtm!

@rustbot label +stable-nominated

Thanks for the review Trevor! Squashed my commits already.

[tgross35]

Ctest is being silly again... these fields might just need to be skipped in libc-test. I'll take a closer look

[tgross35]

Okay I might have an idea here, could you play around with setting a .typ_name override for the types that are failing? Something like

libc/libc-test/build.rs

Lines 706 to 725 in 8c10293

	cfg.type_name(move |ty, is_struct, is_union| {
	match ty {
	// Just pass all these through, no need for a "struct" prefix
	"FILE" | "DIR" | "Dl_info" | "fd_set" => ty.to_string(),
	"Ioctl" => "int".to_string(),
	t if is_union => format!("union {t}"),
	t if t.ends_with("_t") => t.to_string(),
	// sigval is a struct in Rust, but a union in C:
	"sigval" => "union sigval".to_string(),
	// put `struct` in front of all structs:.
	t if is_struct => format!("struct {t}"),
	t => t.to_string(),
	}
	});

, the config for Linux and Android will need to be updated.

[sanstzu]

Okay I might have an idea here, could you play around with setting a .typ_name override for the types that are failing? Something like

libc/libc-test/build.rs

Lines 706 to 725 in 8c10293

	cfg.type_name(move |ty, is_struct, is_union| {
	match ty {
	// Just pass all these through, no need for a "struct" prefix
	"FILE" | "DIR" | "Dl_info" | "fd_set" => ty.to_string(),
	"Ioctl" => "int".to_string(),
	t if is_union => format!("union {t}"),
	t if t.ends_with("_t") => t.to_string(),
	// sigval is a struct in Rust, but a union in C:
	"sigval" => "union sigval".to_string(),
	// put `struct` in front of all structs:.
	t if is_struct => format!("struct {t}"),
	t => t.to_string(),
	}
	});

, the config for Linux and Android will need to be updated.

Okay I might have an idea here, could you play around with setting a .typ_name override for the types that are failing? Something like

libc/libc-test/build.rs

Lines 706 to 725 in 8c10293

	cfg.type_name(move |ty, is_struct, is_union| {
	match ty {
	// Just pass all these through, no need for a "struct" prefix
	"FILE" | "DIR" | "Dl_info" | "fd_set" => ty.to_string(),
	"Ioctl" => "int".to_string(),
	t if is_union => format!("union {t}"),
	t if t.ends_with("_t") => t.to_string(),
	// sigval is a struct in Rust, but a union in C:
	"sigval" => "union sigval".to_string(),
	// put `struct` in front of all structs:.
	t if is_struct => format!("struct {t}"),
	t => t.to_string(),
	}
	});

, the config for Linux and Android will need to be updated.

Sorry for the slow reply, wasn't on GitHub for the past few days and will work on it soon!

[rustbot]

Some changes occurred in solarish module

cc @jclulow, @pfmooney

Some changes occurred in OpenBSD module

cc @semarie

[tgross35]

@sanstzu we now have the updated ctest so things should be less broken. Would you be able to rebase?

[sanstzu]

@sanstzu we now have the updated ctest so things should be less broken. Would you be able to rebase?

Will do, thanks!

[tgross35]

@sanstzu another gentle ping here :)

[rustbot]

Some changes occurred in an Android module

cc @maurer

[tgross35]

I've commandeered this patch since we'd like to have it done (you are still listed as an author). Thank you for getting this started!

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

dismiss