Franco Victorio

Well, I'm still an owner of the package in `npm`, so I just published this fix. Upgrade to `[email protected]` to use the version that has the updated parser.

I think we need to rethink the whole approach to naming, since it's hard to make some calls. For example, the linked docs use mixedCase for immutable variables, but I...

Yeah, I'd be fine with that. Especially because having such a long and ugly option would motivate me to totally redo the naming rules in the next major :smile:

@potomak can you give me a full (compilable) example that includes an assembly block with a `let a, b := ...` assignment?

Thank you. The parser doesn't support that syntax yet, so upgrading won't fix your problem. I created [an issue](https://github.com/solidity-parser/parser/issues/60) in the parser's repo about this.

@joaoh9 this is about solhint not using the default value for that parameter, it's not a question.

@GAUTAMRAJU15 what do you mean by "doesn't work"? Anyway, this issue is for a different scenario, if something doesn't work for you and you have reproduction steps, please open a...

I'm guessing the problem is that doing: ``` solhint Foo.sol ``` doesn't ignore `Foo.sol` even if it's in `.solhintignore`. Is that correct? I'm not sure what is the ideal behavior...

Hi @mdnorman, thanks for reporting this. I guess the exception should be for any imported contract, not only superclasses, right? For example, I don't know if library calls trigger a...

> Even if solhint only works at file-level, it can see the imports, and if it looks at the structure of the contract, it can parse out whether it's a...