diff --git a/swift/internal/compiling.bzl b/swift/internal/compiling.bzl
index 6de61eafb..c23a8281d 100644
--- a/swift/internal/compiling.bzl
+++ b/swift/internal/compiling.bzl
@@ -890,9 +890,9 @@ def _collect_clang_module_inputs(
             # on the file system to map them to the module that contains them.)
             # However, we may also need some of the transitive headers, if the
             # module has dependencies that aren't recognized as modules (e.g.,
-            # `cc_library` targets without the `swift_module` tag) and the
-            # module's headers include those. This will likely over-estimate the
-            # needed inputs, but we can't do better without include scanning in
+            # `cc_library` targets without an aspect hint) and the module's
+            # headers include those. This will likely over-estimate the needed
+            # inputs, but we can't do better without include scanning in
             # Starlark.
             transitive_inputs.append(cc_info.compilation_context.headers)
 
diff --git a/swift/internal/swift_clang_module_aspect.bzl b/swift/internal/swift_clang_module_aspect.bzl
index 314827113..72ac54e62 100644
--- a/swift/internal/swift_clang_module_aspect.bzl
+++ b/swift/internal/swift_clang_module_aspect.bzl
@@ -167,44 +167,6 @@ def create_swift_interop_info(
         unsupported_features = unsupported_features,
     )
 
-def _tagged_target_module_name(label, tags):
-    """Returns the module name of a `swift_module`-tagged target.
-
-    The `swift_module` tag may take one of two forms:
-
-    *   `swift_module`: By itself, this indicates that the target is compatible
-        with Swift and should be given a module name that is derived from its
-        target label.
-    *   `swift_module=name`: The module should be given the name `name`.
-
-    If the `swift_module` tag is not present, no module name is used or
-    computed.
-
-    Since tags are unprocessed strings, nothing prevents the `swift_module` tag
-    from being listed multiple times on the same target with different values.
-    For this reason, the aspect uses the _last_ occurrence that it finds in the
-    list.
-
-    Args:
-        label: The target label from which a module name should be derived, if
-            necessary.
-        tags: The list of tags from the `cc_library` target to which the aspect
-            is being applied.
-
-    Returns:
-        If the `swift_module` tag was present, then the return value is the
-        explicit name if it was of the form `swift_module=name`, or the
-        label-derived name if the tag was not followed by a name. Otherwise, if
-        the tag is not present, `None` is returned.
-    """
-    module_name = None
-    for tag in tags:
-        if tag == "swift_module":
-            module_name = derive_module_name(label)
-        elif tag.startswith("swift_module="):
-            _, _, module_name = tag.partition("=")
-    return module_name
-
 def _generate_module_map(
         actions,
         compilation_context,
@@ -361,22 +323,12 @@ def _module_info_for_target(
     # didn't provide an explicit module map), then don't generate a module map
     # for it. Such modules define nothing and only waste space on the
     # compilation command line and add more work for the compiler.
-    if not (
+    if not module_name or not (
         compilation_context.direct_headers or
         compilation_context.direct_textual_headers
     ):
         return None, None
 
-    if not module_name:
-        # For all other targets, there is no mechanism to provide a custom
-        # module map, and we only generate one if the target is tagged.
-        module_name = _tagged_target_module_name(
-            label = target.label,
-            tags = attr.tags,
-        )
-        if not module_name:
-            return None, None
-
     module_map_file = _generate_module_map(
         actions = aspect_ctx.actions,
         compilation_context = compilation_context,
@@ -671,16 +623,12 @@ artifacts, and so that Swift module artifacts are not lost when passing through
 a non-Swift target in the build graph (for example, a `swift_library` that
 depends on an `objc_library` that depends on a `swift_library`).
 
-It also manages module map generation for `cc_library` targets that have the
-`swift_module` tag. This tag may take one of two forms:
-
-*   `swift_module`: By itself, this indicates that the target is compatible
-    with Swift and should be given a module name that is derived from its
-    target label.
-*   `swift_module=name`: The module should be given the name `name`.
-
-Note that the public headers of such `cc_library` targets must be parsable as C,
-since Swift does not support C++ interop at this time.
+It also manages module map generation for targets that call
+`swift_common.create_swift_interop_info` and do not provide their own module
+map, and for targets that use the `swift_interop_hint` aspect hint. Note that if
+one of these approaches is used to interop with a target such as a `cc_library`,
+the headers must be parsable as C, since Swift does not support C++ interop at
+this time.
 
 Most users will not need to interact directly with this aspect, since it is
 automatically applied to the `deps` attribute of all `swift_binary`,