Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

ethereum/solidity-dev

Solidity compiler development

People

Repo info

Activity

22:34

axic edited #3766
22:23

axic commented #9604
22:17

axic commented #9604
22:16

axic commented #9512
22:12

axic commented #9604
22:10

axic commented #9604
21:57

axic synchronize #10167
21:57

axic on drop-old-reporter

Remove --old-reporter from solc (compare)
21:51

axic commented #7787
21:41

axic closed #9850
21:41

axic commented #9850
21:39

axic commented #7128
21:39

axic commented #7128
21:35

axic commented #5468
21:34

axic edited #5468
21:27

axic commented #9160
21:26

axic commented #9160
21:22

axic edited #10167
21:21

axic edited #10167
21:19

axic opened #10167

Harikrishnan Mulackal

@hrkrshnn

@cameel Was info about the switch published somewhere?

Gabriele Rigo

@gabririgo

ok @cameel thank you for your help

Kamil Śliwak

@cameel

And the biggest problem with it was really that it's not our domain and we can't really switch it to something else. That's why we're recommending https://solc-bin.ethereum.org instead. It used to point at GH pages too but we've been able to seamlessly switch to S3 so everyone using it didn't even notice anything. If you use it, you will avoid this kinds of problems if we need to switch again.

@hrkrshnn Not really because it was meant to be a seamless change and using the GH pages domain wasn't really ever recommended.
But you have a point, from time to time someone reports this so I guess we should at least post on Twitter or something.

I've been also meaning to put it in solc-bin README. I think I'll do that now.

Franziska Heintel

@franzihei

@cameel I think we're good with the AMA

thanks for posting your answers°

Harikrishnan Mulackal

@hrkrshnn

Maybe @franzihei can tweet about it.

Franziska Heintel

@franzihei

I don't think there's any important question left unanswered. :)

Kamil Śliwak

@cameel

Great!

Franziska Heintel

@franzihei

I can tweet about the solc-bin.ethereum

what is the recommendation exactly?

Kamil Śliwak

@cameel

Basically that we have changed the hosting behind https://solc-bin.ethereum.org and the transition should have been seamless for anyone who has been using it but the files were also available via https://ethereum.github.io/solc-bin/ and anyone using it should switch.
We don't control that domain so we can't do anything about it ourselves. It's serving an older snapshot of the repo, new binaries won't show up there and it does not have the older Linux/Mac/Windows builds we recently started providing.

Franziska Heintel

@franzihei

ok will communicate that just to make sure everybody switches :thumbsup:

Kamil Śliwak

@cameel

Thanks. I'll also update the README, though getting it to show up at https://ethereum.github.io/solc-bin/ will be tricky (would require temporarily removing some files to go below the limit again and get GH pages to update one last time) so the tweet will be very helpful.

Alex Beregszaszi

@axic

@cameel not sure I understood your concern on #10147 ?

Kamil Śliwak

@cameel

My concern is that your change basically ignores m_generateEvmBytecode if necessary.

Alex Beregszaszi

@axic

How come it ignores it?

Kamil Śliwak

@cameel

But that seems to be done only because CLi does not do it at a higher level

ok, sorry, to be precise it skips compileContract(*contract, otherCompilers);, i.e. ignores (disables) the evm bytecode compilation

which used to be the effect of m_generateEvmBytecode.

Alex Beregszaszi

@axic

generateEVMFromIR is the replacement for acompileContract — the whole point of the issue this implements is to change the internal pipeline to IR and compileContract is the only piece which does the old route, but both functions output the same fields

Kamil Śliwak

@cameel

I mean, it's an alternative for it.

You can call one, the other or none of them.

Alex Beregszaszi

@axic

I just don’t see how EVM bytecode generation is skipped in the PR.

Kamil Śliwak

@cameel

Maybe I'll try to explain in a different way. My primary concern is this:
https://github.com/ethereum/solidity/blob/develop/libsolidity/interface/StandardCompiler.cpp#L913

Alex Beregszaszi

@axic

What does that has to do with the IR?

Kamil Śliwak

@cameel

i.e. standard JSON already has code to decide whether to enable evm bytecode compilation or not. and m_generateEvmBytecode was just a dumb flag

Alex Beregszaszi

@axic

I think you may be misreading the diff in the PR because the logic is not changed

Or perhaps you are talking about introducing further clarification which is tangential to the PR?

Kamil Śliwak

@cameel

Let's put it differently: why not do enableEvmBytecodeGeneration(!m_viaIR) in CommandLineInterface.cpp instead?

It would be more in line with what standard JSON does.

Alex Beregszaszi

@axic

The viaIR option is not only for the EVM output, but plenty of others.

It changes the source maps, the gas estimates, etc.

Kamil Śliwak

@cameel

I'm not saying to remove it.

I'm just wondering why standard JSON enables/disables evm compilation via enableEvmBytecodeGeneration() while CLI goes around it.

Alex Beregszaszi

@axic

The original discussion which this PR fixes is #8722 and that proposes the exact thing you are saying, but now I am more on the side with @chriseth that switching the pipeline is a clearer option.

I'm just wondering why standard JSON enables/disables evm compilation via enableEvmBytecodeGeneration() while CLI goes around it.

Because nobody cares about the CLI. We have been asking everyone to move over to the standard json. I consider the non-standard-json options of the CLI for compiler development purposes, and not as production tools.

Kamil Śliwak

@cameel

No, that's not what I mean. I'm not saying that your options should be an output options.

Alex Beregszaszi

@axic

Please read #8722 :)

Kamil Śliwak

@cameel

I've read it already :)

Alex Beregszaszi

@axic

#8722 says to add an output option, —ir-bin.

Kamil Śliwak

@cameel

Yeah. And that's not what I'm saying. I know that your option just changes the pipeline so that the --bin output starts coming from IR.

Alex Beregszaszi

@axic

I'm just wondering why standard JSON enables/disables evm compilation via enableEvmBytecodeGeneration() while CLI goes around it.

I’m not sure what the CLI is doing, but that thing is added to the standard json for speed purposes — to avoid generating that code in the first place. I assume the CLI just filters afterwards, as was the JSON interface doing initially. And the json interface is the one used by most so that is speed critical. Probably someone forgot to update the CLI code.

Kamil Śliwak

@cameel

ok, my bad, I reread what you wrote here and looks like I got it wrong. Sorry.
I mean, I understand what #8722 says and the difference between --ir-bin and your flag. Just for some reason I was interpreting the meaning of m_generateEvmBytecode in different ways in different contexts...

Alex Beregszaszi

@axic

No worries, sorry if I came across as a bit antsy :)

Just knew that it would take forever resolving this via github comments.

Kamil Śliwak

@cameel

Right :)

Leonardo

@leonardoalt

@mijovic ethereum/solidity#10120 and ethereum/solidity#10139 still need to be reviewed though

Đorđe Mijović

@mijovic

@leonardoalt ah, missed them. Will do review. Also, what is state of CHC early return PR?

Alex Beregszaszi

@axic

Every time I try to close some projects or issues, it turns into finding some obscene rabbit hole.