move absl namespace to int128 inc files

[HannahShiSFB]

This fixes the modules-import-nested-redundant error in grpc swift build

[/absl/numeric/int128.h:1182](https://cs.corp.google.com/piper///depot/google3/Users/kbuilder/Library/Developer/Xcode/DerivedData/workspace_objc_macos_opt_native-auypnimqokfdevhekumkyzytzaba/SourcePackages/checkouts/abseil-cpp-SwiftPM/absl/numeric/int128.h?l=1182&ws&snapshot=0):1: error: redundant #include of module 'abseil' appears within namespace 'absl::lts_20240722' [-Wmodules-import-nested-redundant]
#include "absl/numeric/int128_have_intrinsic.inc"  // IWYU pragma: export
^
/[Users/kbuilder/Library/Developer/Xcode/DerivedData/workspace_objc_macos_opt_native-auypnimqokfdevhekumkyzytzaba/SourcePackages/checkouts/abseil-cpp-SwiftPM/absl/numeric/int128.h:557](https://cs.corp.google.com/piper///depot/google3/Users/kbuilder/Library/Developer/Xcode/DerivedData/workspace_objc_macos_opt_native-auypnimqokfdevhekumkyzytzaba/SourcePackages/checkouts/abseil-cpp-SwiftPM/absl/numeric/int128.h?l=557&ws&snapshot=0):1: note: namespace 'absl::lts_20240722' begins here
ABSL_NAMESPACE_BEGIN
^

CC: @sampajano

[derekmauro]

As far as I know, the code here is completely legal as-is. You can use a .inc file to include arbitrary code into another file. This means that, for example, it is completely legal to "paste" code into another namespace.

https://clang.llvm.org/docs/DiagnosticsReference.html#wmodules-import-nested-redundant

The error here is

error: redundant #include of module ‘A’ appears within B

I think the problem may have something to do with the podspec configuration (which I know little about). If I recall correctly @veblush wrote it.

abseil-cpp/absl/abseil.podspec.gen.py

Lines 183 to 205 in d79e680

	def write_podspec_rule(f, rule, depth):
	"""Writes podspec from given rule."""
	indent = " " * (depth + 1)
	spec_var = get_spec_var(depth)
	# Puts all files in hdrs, textual_hdrs, and srcs into source_files.
	# Since CocoaPods treats header_files a bit differently from bazel,
	# this won't generate a header_files field so that all source_files
	# are considered as header files.
	srcs = sorted(set(rule.hdrs + rule.textual_hdrs + rule.srcs))
	write_indented_list(
	f, "{indent}{var}.source_files = ".format(indent=indent, var=spec_var),
	srcs)
	# Writes dependencies of this rule.
	for dep in sorted(rule.deps):
	name = get_spec_name(dep.replace(":", "/"))
	f.write("{indent}{var}.dependency '{dep}'\n".format(
	indent=indent, var=spec_var, dep=name))
	# Writes dependency to xcprivacy
	f.write(
	"{indent}{var}.dependency '{dep}'\n".format(
	indent=indent, var=spec_var, dep="abseil/xcprivacy"
	)
	)

To me it looks like the problem is that the podspec is treating the .inc files as separate modules and compiling them, when they shouldn't ever be compiled outside of another context.

[HannahShiSFB]

The failure was from swift build failure which does not use podspec but https://github.com/firebase/abseil-cpp-SwiftPM.
This PR is follow the pattern of other .inc files where they are not put in namespaces.

[derekmauro]

I'm not sure what point you are trying to make when you say you are just following a pattern. If this isn't working, something is wrong with the build. The code is completely legal.

[HannahShiSFB]

It's probably legal but maybe not compatible with all build systems.
I checked all other inc files, none of them were put under a namespace. For instance https://github.com/abseil/abseil-cpp/blob/master/absl/time/clock.cc#L62-L66
It's just easier that behave the same as normal header files and can be handled as normal headers.

[derekmauro]

It's probably legal but maybe not compatible with all build systems.

Can you file a bug against the build system then?

Or, for example, maybe you need to exclude the .inc files like this does? https://github.com/swiftlang/indexstore-db/blob/1e3bf2d2b82a6428d8d63ee3e239b189c32fda50/Package.swift#L130

I checked all other inc files, none of them were put under a namespace. For instance https://github.com/abseil/abseil-cpp/blob/master/absl/time/clock.cc#L62-L66
It's just easier that behave the same as normal header files and can be handled as normal headers.

I'm not buying this line of reasoning. It happens to be easy enough to work around this here, but there may come a time where we want to implement something and where it would not be convenient to use this workaround. And these are not normal headers, nor can they be.

[HannahShiSFB]

I can try exclude the .inc files but it only helps for the swift package.
I don't think this PR is a workaround. There is no such thing as .inc files in standard, they should be either source files or header files, in this case they are just headers with non-conventional names, but they don't behave like normal headers and these two files are the only cases in abseil-cpp codebase.