Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:26
    frangio commented #11531
  • 00:25
    frangio commented #11531
  • 00:25
    frangio commented #11531
  • Jun 23 22:08
    cameel commented #11489
  • Jun 23 21:53
    haltman-at commented #11489
  • Jun 23 20:17
    cameel unlabeled #11573
  • Jun 23 20:16
    cameel labeled #11573
  • Jun 23 19:42
    haltman-at commented #11508
  • Jun 23 19:42
    cameel labeled #9874
  • Jun 23 19:31
    cameel edited #11518
  • Jun 23 19:30
    cameel commented #11572
  • Jun 23 19:29
    cameel commented #11572
  • Jun 23 19:29
    cameel commented #11572
  • Jun 23 17:35

    chriseth on develop

    [yul] Functions: Remove depende… Merge pull request #11512 from … (compare)

  • Jun 23 17:35

    chriseth on issue_10342

    (compare)

  • Jun 23 17:35
    chriseth closed #11512
  • Jun 23 17:35
    chriseth closed #10342
  • Jun 23 17:11
    cameel commented #11489
  • Jun 23 17:11
    cameel commented #11489
  • Jun 23 16:54
    cameel commented #11489
cameel
@cameel:matrix.org
[m]
ok
chriseth
@chriseth:matrix.org
[m]
meeting in 2 minutes: https://meet.komputing.org/solidity
christianparpart
@christianparpart:matrix.org
[m]
yes. just came back from kitchen :)
hrkrshnn
@hrkrshnn:matrix.org
[m]
About PRs, ethereum/solidity#11525 generally looks good (although, will have to look again after the reviewing the code transform.) Maybe something to consider is if we can first run some optimization steps (for example loop condition into body) to the AST, which would simplify the graph generation code. But yeah, you can also take a look chriseth
cameel
@cameel:matrix.org
[m]
I assumed it's the optimizer replacing PUSH1 1 with an equivalent that takes just one byte.
Not entirely sure if that's the case though.
axic
@axic:matrix.org
[m]
i don't think we have returndatasize for that yet :)
i strongly argued against that
1 reply
the main question there (but I think it also applies in general) is if importing a file with a using statement makes the statement apply in the current file or not
or if you have to repeat the using statement all the time
Marenz: and in general: Do we want to have a mode where in the --ir output, the @src annotation does not only contain the source location but also the source text at that location?
chriseth
@chriseth:matrix.org
[m]
(like we have in --asm)
maybe --ir-verbose?
or would we also have a mode without source annotations?
(and thus have a general switch about what to put in the iR)?
Marenz
@m4renz:matrix.org
[m]
I suppose the question is who would is it how.
With the source location it is probably very useful for debugging
without anything it's useful for anything that just wants to process it further, but filtering that out manually (or ignoring it) is also very easy
cameel
@cameel:matrix.org
[m]

or if you have to repeat the using statement all the time

We did change it for contracts so that you have to repeat it if you inherit. Would make sense if it was the same here - you have to repeat it in every file (assuming it's a file-level construct).

On the other hand this would prevent libraries from doing it for the user. Repeating it might not only be tedious for the user but the user might not even be aware what is availalble for what type without reading the whole library code.

So not sure. Is the argument that user should be familiar with all the library code he's using a good one? :)
chriseth
@chriseth:matrix.org
[m]
maybe we could find another statement that is really attached to the type
or a variation of using
like using {...} for T everywhere;
but the statement creates an error if T is not defined in the same scope
(or a sub-scope)
or it has to be attached to the definition somehow?
So that you have to repeat using for built-in types, but you can make it "stick" to user-defined types
the problem is that you can use import Typename from "file.sol";
(and you should)
how does rust do that with its traits?
axic
@axic:matrix.org
[m]
Can not implement foreign traits on foreign types, either the trait or the type has to be local to your scope.
chriseth
@chriseth:matrix.org
[m]
either?
ok, so there is the type (=datastructure), then there is the trait (=interface) and the implementation of the trait, right?
1 reply
and the implementation of the trait is always specific to the type, but the trait is generic
1 reply
and if I import the type but not the trait, then I cannot use the function
1 reply
and what about importing the trait implementation without the trait or without the type?
1 reply
chriseth
@chriseth:matrix.org
[m]
what happens if there are two traits that declare the same function? Do I name the trait when I call the function and both traits are visible?
axic
@axic:matrix.org
[m]
I can't remember now as I havent used it for half a year, but either you can't implement conflicting ones or there is a way to call explicitly
error[E0599]: no method named `test` found for struct `C` in the current scope
  --> bindings/rust/src/lib.rs:63:7
   |
51 | struct C(i32);
   | -------------- method `test` not found for this
...
63 |     c.test();
   |       ^^^^ this is an associated function, not a method
   |
   = note: found the following associated functions; to be used as methods, functions must have a `self` parameter
note: candidate #1 is defined in the trait `A`
  --> bindings/rust/src/lib.rs:44:4
   |
44 |    fn test();
   |    ^^^^^^^^^^
note: candidate #2 is defined in the trait `B`
  --> bindings/rust/src/lib.rs:48:4
   |
48 |    fn test();
   |    ^^^^^^^^^^
   = help: items from traits can only be used if the trait is implemented and in scope
   = note: the following traits define an item `test`, perhaps you need to implement one of them:
           candidate #1: `A`
           candidate #2: `B`
help: disambiguate the associated function for candidate #1
   |
63 |     A::test(c);
   |     ^^^^^^^^^^
help: disambiguate the associated function for candidate #2
   |
63 |     B::test(c);
   |     ^^^^^^^^^^

error: aborting due to previous error
So basically typecasting is needed in that case
chriseth
@chriseth:matrix.org
[m]
ok, makes sense. Thanks!
axic
@axic:matrix.org
[m]
Re #11512 I did not have time to try to understand all of it again, it does feel like not being the final solution, but it does not seem to hurt and at least improve many cases.
But what is the reason for the bool in internalFunctionID, in what cases does it matter that it was an already existing id?
chriseth
@chriseth:matrix.org
[m]
it is just for the additional check that the internal dispatch routine does not use any function IDs for functions that have not been generated
axic
@axic:matrix.org
[m]
Just an assertion for the dispatch generator?
yeah makes sense, perhaps documenting it as a comment in the dispatch generator would have been enough
StackenBotten
@stackenbotten
✅ Nightly job t_ems_test_ext_colony succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/759975 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ubu_ossfuzz succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/759978 for details.