No warning for an associated constant always hidden by an enum variant

[scottmcm]

To my great surprise, this compiles fine, with no warnings:

pub enum Foo {
    A(i32),
}
impl Foo {
    pub const A: Self = Foo::A(0);
}

Trying to actually use that constant, however, doesn't work:

pub fn demo() -> Foo {
    Foo::A
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d1e7c140a60c78cc6ede62b677a74e5e

error[E0308]: mismatched types
 --> src/lib.rs:9:5
  |
2 |     A(i32),
  |     ------ fn(i32) -> Foo {Foo::A} defined here
...
8 | pub fn demo() -> Foo {
  |                  --- expected `Foo` because of return type
9 |     Foo::A
  |     ^^^^^^ expected enum `Foo`, found fn item
  |
  = note: expected enum `Foo`
          found fn item `fn(i32) -> Foo {Foo::A}`
help: use parentheses to instantiate this tuple variant
  |
9 |     Foo::A(_)
  |           ^^^

If that constant is going to compile, it should probably at least be linted against.

[petrochenkov]

IIRC, when "variants as associated items" were accepted, the decision was to report an associated item overlap error similar to

struct S;
impl S { fn a() {} }
impl S { fn a() {} } //~ ERROR

in situations like this.

[jyn514]

I recently discovered this in rustdoc: #75756 (comment). I guess rustdoc should track the rustc behavior (right now it's buggy and gives the const precedence):

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Lines 113 to 122 in 085e417

	Res::Def(DefKind::Enum, did) => {
	if cx
	.tcx
	.inherent_impls(did)
	.iter()
	.flat_map(|imp| cx.tcx.associated_items(*imp).in_definition_order())
	.any(|item| item.ident.name == variant_name)
	{
	return Err(ErrorKind::ResolutionFailure);
	}

So give the variant precedence now and change it when/if rustc changes it.

[scrabsha]

Can I start working on it?

[scrabsha]

IIRC, when "variants as associated items" were accepted, the decision was to report an associated item overlap error similar to

struct S;
impl S { fn a() {} }
impl S { fn a() {} } //~ ERROR

in situations like this.

@petrochenkov, can you post a link of where this has been discussed?

Also, this would break the test ui/type-alias-enum-variants/enum-variant-priority-higher-than-other-inherent.rs. I am not sure if I should just remove the relevant code.

By the way, should we emit an error when a function name is the same as an enum variant?

[scottmcm]

Looks like this is related to #48758 (comment)

[petrochenkov]

Closing as a duplicate of #48758.