Potentially ambiguous glob re-exports in `core_arch/src/arm/mod.rs`

[jieyouxu]

Hi, I was working on rust-lang/rust#107880, and came across

stdarch/crates/core_arch/src/arm/mod.rs

Lines 73 to 81 in 7fbf697

	pub use crate::core_arch::arm_shared::*;
	#[cfg(test)]
	use stdarch_test::assert_instr;
	#[cfg(any(target_feature = "v7", doc))]
	pub(crate) mod neon;
	#[cfg(any(target_feature = "v7", doc))]
	pub use neon::*;

I think this is a case of potentially ambiguous glob re-exports because functions under arm_shared::neon is re-exported alongside neon. If a downstream user (or in docs) tries to use a function that is present in both neon and arm_shared namespaces then an error will occur (provided target feature v7 or doc is enabled).

E.g. the WIP error message reveals a potential ambiguous function vcvtq_u32_f32:

error[E0252]: the name `vcvtq_u32_f32` is defined multiple times
  --> /checkout/library/core/src/../../stdarch/crates/core_arch/src/arm/mod.rs:81:9
   |
73 | pub use crate::core_arch::arm_shared::*;
   |         -------------------------------
   |         |
   |         previous import of the value `vcvtq_u32_f32` here
   |         you can use `as` to change the binding name of the import
...
81 | pub use neon::*;
   |         ^^^^^^^ `vcvtq_u32_f32` reimported here
   |
   = note: `vcvtq_u32_f32` must be defined only once in the value namespace of this module

If it is intended that vcvtq_u32_f32 from neon should override the re-export from the glob re-export of arm_shared::*, then I think it needs to be specified by name, i.e.

pub use crate::core_arch::arm_shared::*;
pub use neon::vcvtq_u32_f32;

In this case, vcvtq_u32_f32 will override the function of the same name from arm_shared::* because it is named and not a glob re-export.

[Amanieu]

This is accidental, there definitely shouldn't be any overlap between arm/aarch64 and arm_shared. It's a good thing your lint catches this!

Is vcvtq_u32_f32 the only function that triggers this or are there also others?

[jieyouxu]

This is accidental, there definitely shouldn't be any overlap between arm/aarch64 and arm_shared. It's a good thing your lint catches this!

Is vcvtq_u32_f32 the only function that triggers this or are there also others?

I'm still working on the lint, I think there could be a couple more functions. Currently the lint is just a hard error and I think stops on the first collision because I was still trying to combat false positives :3

[jieyouxu]

Sorry about this, I think it is a false positive because rust-lang/rust#107880 (comment) (TL;DR: the one in arm shadows the one in arm_shared).