D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 18973 - @disable on const toHash causes unresolved symbol error
Summary: @disable on const toHash causes unresolved symbol error
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P1 minor
Assignee: No Owner
URL:
Keywords: link-failure, pull, rejects-valid
Depends on:
Blocks:
 
Reported: 2018-06-12 08:56 UTC by elpenguino+D
Modified: 2022-07-07 10:16 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description elpenguino+D 2018-06-12 08:56:25 UTC
Annotating const toHash methods with @disable causes unresolved symbol errors in the link stage.

```
struct X {
    @disable size_t toHash() const;
}
```

will cause

```
onlineapp.o:onlineapp.d:_D22TypeInfo_S9onlineapp1X6__initZ: error: undefined reference to '_D9onlineapp1X6toHashMxFZm'
```
Comment 1 LucienPe 2020-05-09 15:24:04 UTC
That has nothing to do with the @disable attribute.
It's because you need to add a body to `toHash()`.

Like this:
```

    @disable size_t toHash() const
    {
        return 0;
    }

```

For the v2.091 of DMD:

```
struct X
{
    @disable size_t toHash() const nothrow @safe
    {
        return 0;
    }
}
```
Comment 2 elpenguino+D 2020-05-09 19:13:50 UTC
Incorrect. a @disabled method does not need a body, as no references to it are ever emitted. You can observe this for yourself by simply renaming toHash in the example to something without special semantics. Or by removing const. Even a non-@disable'd method without a body doesn't generate linker errors unless you try to call it.
Comment 3 LucienPe 2020-05-09 21:28:09 UTC
(In reply to elpenguino+D from comment #2)
> Incorrect. a @disabled method does not need a body, as no references to it
> are ever emitted. You can observe this for yourself by simply renaming
> toHash in the example to something without special semantics. Or by removing
> const. Even a non-@disable'd method without a body doesn't generate linker
> errors unless you try to call it.

You're right. That was a workaround :P
This bug is also valid for `toString()`.

```
struct Foo
{
	@disable size_t toHash() const nothrow @safe; // linker fail
	@disable size_t toHash(); // ok
	@disable string toString(); // linker fail
}

class Bar
{
	@disable override size_t toHash() const nothrow @safe; // linker fail
	@disable override size_t toHash(); // linker fail
	@disable override string toString(); // linker fail
}
```
Comment 4 Dlang Bot 2022-07-07 04:41:16 UTC
@Geod24 created dlang/dmd pull request #14272 "Fix 18973 - TypeInfo generation does not account for `@disable`" fixing this issue:

- Fix 18973 - TypeInfo generation does not account for `@disable`
  
  This changes `overloadExactMatch` as all 14 usages of it are to find
  functions that can later be called.

https://github.com/dlang/dmd/pull/14272
Comment 5 Dlang Bot 2022-07-07 10:16:21 UTC
dlang/dmd pull request #14272 "Fix 18973, 9161 - TypeInfo generation does not account for `@disable`" was merged into master:

- 22e4aecb13b7020cbc4525e6eb0a4d77b7528d74 by Geod24:
  Fix 18973 - TypeInfo generation does not account for `@disable`
  
  This changes `overloadExactMatch` as all 14 usages of it are to find
  functions that can later be called.

https://github.com/dlang/dmd/pull/14272