Show inherited functions in Debug (when deploying with hardhat)

[FilipHarald]

Description

This adds information in the Debug-view. It's now possible to see which functions are inherited, and from where they are inherited. Unfortunately, functions that use override show up with inherited tooltip.

Additional Information

• I have read the contributing docs (if this is your first contribution)
• This is not a duplicate of any existing pull request

Related Issues

Related discussion: #558

Your ENS/address: harmont.eth

[FilipHarald]

I still need to add this to the view-vars and read-functions.

But I started the PR so I can get some feedback or tips on the UI.

[FilipHarald]

The first two commits are implemented with tooltip and data-tip. But in the current branch I try to build my own tooltip. But it's a bit tricky.

function-origin2.mp4

[FilipHarald]

Also, I don't think this will work when overriding functions.

[FilipHarald]

I made some modifications now. This is how it looks:

function-origin3.mp4

[FilipHarald]

I don't know if I should split packages/hardhat/deploy/99_generateTsAbis.ts or keep it as is?

Also, the tooltip looks the same for all three (vars, readFunc and writeFunc) should I make that to a seperate component or keep them where they are now?

[carletex]

This is looking great @FilipHarald !!

Left some minor comments. Also tagging Shiv & Rinat so the can test and review.

Thanks!

[rin-st]

Thank you for pr, @FilipHarald !

Noticed that color of tooltip in light mode the same as bg of methods list.

And I'm not sure that we want to sort methods: own in alphabetical order -> inherited it alphabetical order. It's good but I think often inherited methods are main. You don't need to change it right now, I wrote it just to discuss

Other than that looks good, gj!

[FilipHarald]

Thanks for the review @rin-st !

Noticed that color of tooltip in light mode the same as bg of methods list. ...

Oh, you're right. I can see if I there is an easy fix.

And I'm not sure that we want to sort methods: own in alphabetical order -> inherited it alphabetical order. It's good but I think often inherited methods are main. You don't need to change it right now, I wrote it just to discuss

OK, I would be happy to discuss this. I can tell you my reasoning and I'd be happy to hear yours! So for me this is a problem because I'm still new to Solidity. So when I extend some interface, like Ownable, I get some functions that I don't know what they're doing yet. For Ownable specifically, I'm not using any of the functions. I'm just using the modifier on my own defined functions. That's why I want them at the bottom :)

[rin-st]

That's why I want them at the bottom

In some cases you need to use inherited methods often. But I think sorted is ok, at least it's easy to find what you need.

One more thing. Noticed that when you override inherited methods, it's still marked as inherited. Is it possible to mark that methods "overridden" or "inherited, overridden"?

And if possible sort: own -> overridden -> other inherited

[technophile-04]

Unfortunately, functions that use override show up with inherited tooltip

Noticed that when you override inherited methods, it's still marked as inherited. Is it possible to mark that methods "overridden" or "inherited, overridden"?

Also find a kind of edge case which is kidof related to above comments, when you just import a contract but don't inherit it it still gives inherited :

Example Contract :

//SPDX-License-Identifier: MIT
pragma solidity >=0.8.0 <0.9.0;

// Use openzeppelin to inherit battle-tested implementations (ERC20, ERC721, etc)
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract {
	// State Variables
	address public immutable owner;

	constructor(address _owner) {
		owner = _owner;
	}
}

---

Also one thing I think it would be really great if we make inheritedFunctions: InheritedFunctions; optional in contract.ts
and handle the same case in Debug Contracts components.

Because there might a slight case where we couldn't get this data in foundry and it will break frontend for foundry when people use it through CLI(#436)

also if we people want to add external contracts which they already have deployed it might be hard from them to get this inheritedFunctions data if they want to manually put abi and address in deployedContracts.ts file

Tysm @FilipHarald great job!!

[FilipHarald]

Replying to both of these:
@rin-st :

One more thing. Noticed that when you override inherited methods, it's still marked as inherited. Is it possible to mark that methods "overridden" or "inherited, overridden"?

And if possible sort: own -> overridden -> other inherited

@technophile-04 :

Also find a kind of edge case which is kidof related to above comments, when you just import a contract but don't inherit it it still gives inherited :

The problem is that I have not yet found any linking of what is an inherited function and not. The only thing I'm doing is looking at the imported contracts, and then cross-reference the functions in their contracts with the ones in the current one. But the current contract will not show if the function in the ABI if it is overridden or not. Maybe it's possible to get from when compiling the Solidity, but I have not yet found a solution to this.

[FilipHarald]

Currently, the only "blocker" is the edge-cases that I summarized above. (#564 (comment))

[technophile-04]

I think this looks almost ready for merge 🙌

Currently, the only "blocker" is the edge-cases that I summarized above. (#564 (comment))

Yup to summarize, we get unwanted Inherited Tooltip from on functions :

1. When we override a function
2. When we have an unused Import contract which internally has the same name as our contract function (Show inherited functions in Debug (when deploying with hardhat) #564 (comment))

Even I tried debugging it but no luck finding a solution with all the available / generated / compiled files :(

Nevertheless, I think this is ready to merge since 1st edge case feels not that deal breaker and 2nd one is very less likely to happen

But let's see what others have to say 🙌, Tysm @FilipHarald for proposing and tackling it !!

[rin-st]

Looks much better!

I found one more edge case, sorry 😄 . It's very rare and I don't know if someone will ever meet it.

See solidity-by-example . I copied contracts and everything works as expected, except contract E - it should show "inherited from contracts/B.sol" or "inherited from contracts/C.sol, contracts/B.sol"

I'm not sure if we need to consider this, but if it's fixable I think we need to do it.
Branch with this case https://github.com/scaffold-eth/scaffold-eth-2/tree/inherited-edge-case

[technophile-04]

Tysm @rin-st great find 🙌

Created FilipHarald#1 which solves :

#564 (comment) and #564 (comment)

[FilipHarald]

I think everything is merged now. Thanks again @rin-st and @technophile-04 for help with edge-cases.

[rin-st]

lgtm!

[technophile-04]

Tysm @FilipHarald 🙌, I think this is really nice !!

Next steps :

1. Let's get it working for foundry

2. And try to solve pt.1 for Show inherited functions in Debug (when deploying with hardhat) #564 (comment)

Thanks again !!