May 02, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Fri, 02 May 2014 15:54:37 -0400 Nick Sabalausky via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Warnings ARE a built-in lint-like tool. Perhaps, but having them in the compiler is inherently flawed, because you have little-to-no control over what it warns about, and you're forced to essentially treat them as errors, because it's incredibly error-prone to leave any warnings in the build (they mask real problems too easily). As such, it makes no sense to have warnings in the compiler IMHO. > On top of that, lint itself proves that lint tends to not get used. True, that is a problem. But if folks really want the warnings, they can go to the extra effort. And I'd much rather err on the side of folks screwing up because they didn't bother to run the tool than having to fix nonexistent problems in my code because someone convinced a compiler dev to make the compiler warn about something that's a problem some of the time but isn't a problem in what I'm actually doing. - Jonathan M Davis |
May 02, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via Digitalmars-d wrote:
> True, that is a problem. But if folks really want the warnings, they can go to the extra effort.
Why are we making people go to extra effort to get lint-like functionality if we want it to be something that everyone uses? Whether a linter is a separate logical entity within the compiler or a library that can be hooked into, it should be on by default.
|
May 03, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On Fri, 02 May 2014 22:39:12 +0000
Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via Digitalmars-d wrote:
> > True, that is a problem. But if folks really want the warnings, they can go to the extra effort.
>
> Why are we making people go to extra effort to get lint-like functionality if we want it to be something that everyone uses? Whether a linter is a separate logical entity within the compiler or a library that can be hooked into, it should be on by default.
The problem that some of what gets warned about is _not_ actually a problem. If it always were, it would be an error. So, unless you have control over exactly what gets warned about and have the ability to disable the warning in circumstances where it's wrong, it makes no sense to have the warnings, because you're forced to treat them as errors and always "fix" them, even if the fix is unnecessary. If the compiler provides that kind of control, then fine, it can have warnings, but dmd doesn't and won't, because Walter doesn't want it to have a vast assortment of flags to control anything (warnings included). That being the case, it makes no sense to put the warnings in the compiler. With a lint tool however, you can configure it however you want (especially because there isn't necessarily one, official tool, making it possible to have a lint tool that does exactly what you want for your project). It's not tied to what the language itself requires, making it much more sane as a tool for giving warnings. The compiler tends to have to do what fits _everyone's_ use case, and that just doesn't work for warnings.
Putting warnings in the compiler always seems to result in forcing people to change their code to make the compiler shut up about something that is perfectly fine.
- Jonathan M Davis
|
May 03, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Saturday, 3 May 2014 at 01:17:36 UTC, Jonathan M Davis via Digitalmars-d wrote:
> The problem that some of what gets warned about is _not_ actually a problem.
> If it always were, it would be an error. So, unless you have control over
> exactly what gets warned about and have the ability to disable the warning
> in circumstances where it's wrong, it makes no sense to have the warnings,
> because you're forced to treat them as errors and always "fix" them, even if
> the fix is unnecessary. If the compiler provides that kind of control, then
> fine, it can have warnings, but dmd doesn't and won't, because Walter doesn't
> want it to have a vast assortment of flags to control anything (warnings
> included). That being the case, it makes no sense to put the warnings in the
> compiler. With a lint tool however, you can configure it however you want
> (especially because there isn't necessarily one, official tool, making it
> possible to have a lint tool that does exactly what you want for your
> project). It's not tied to what the language itself requires, making it much
> more sane as a tool for giving warnings. The compiler tends to have to do
> what fits _everyone's_ use case, and that just doesn't work for warnings.
>
> Putting warnings in the compiler always seems to result in forcing people to
> change their code to make the compiler shut up about something that is
> perfectly fine.
>
> - Jonathan M Davis
I'm not arguing for warnings in the compiler. If we agree that a linter is a good thing that everyone should use, then we should make it as easy as possible to use it - including having it on by default. It's fine if it's customizable, disable-able, etc. Then the users that want to tweak its behaviour or go without can do so.
As for what "having it on by default" means, that's up for debate. Currently, only the determined can use, for example, DScanner, as they have to clone the Github repo, compile it, and then set it up to use with their editor of choice. DScanner hasn't become a de-facto standard yet, or "officially blessed", of course, but as soon as that happens, rapid action needs to be taken to ensure that it is as painless as possible to use and enabled by default, preferably transparent to the casual or uninformed user.
|
August 31, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | Am Fri, 02 May 2014 01:56:49 +0000 schrieb "bearophile" <bearophileHUGS@lycos.com>: > Temtaime: > > > I think it's need to have -w64(or other name, offers ?) flag that warns if code may not compile on other archs. > > It's a problem and I'd like some way to compiler help solving such problems. > > I suggested this, that was refused (I don't remember who reopened > it): > https://issues.dlang.org/show_bug.cgi?id=5063 > > Bye, > bearophile That would have be me going renegade against a RESOLVED-WONTFIX after I found a library that wouldn't compile on my amd64 because it mixed size_t and uint as if it was the same. Later I found a little flood of bug reports for other libraries as well. Whether a warning or size_t as a distinct type like some other language does, the current situation is the source of statically checkable, avoidable portability bugs. -- Marco |
August 31, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | Am Sat, 03 May 2014 03:17:23 +0200 schrieb Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com>: > […] > > Putting warnings in the compiler always seems to result in forcing people to change their code to make the compiler shut up about something that is perfectly fine. > > - Jonathan M Davis I agree with you about warnings about clarity of operator precedence and the like, where it is just a matter of style. But I don't see what that has to do with this issue and code like: size_t = ulong; // breaks when porting from 64 to 32 bit uint = size_t; // breaks when porting from 32 to 64 bit which is obviously broken, but accepted. I would really like to force people to change their code to make the compiler shut up. See some of the linked bugs for examples: https://issues.dlang.org/show_bug.cgi?id=5063#c4 Now we have 3 bad options and no good one: :( - add warnings to dmd, which should never have real warnings and dozens of flags to control them - make size_t a distinct type, which is unfeasible to implement and is likely to break _something_ - keep the status quo with libraries that don't compile and try to educate people about the issue -- Marco |
September 01, 2014 Re: DIP(?) Warning to facilitate porting to other archs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | "Marco Leise" wrote in message news:20140831232805.7fe19a60@marco-leise.homedns.org... > size_t = ulong; // breaks when porting from 64 to 32 bit > uint = size_t; // breaks when porting from 32 to 64 bit > > which is obviously broken, but accepted. I would really like > to force people to change their code to make the compiler shut > up. See some of the linked bugs for examples: > https://issues.dlang.org/show_bug.cgi?id=5063#c4 > Maybe it's just my history with C, but I'm always really pleased when this kind of code errors out the first time it's compiled on 64-bit. Since dmd is always a cross-compiler, just can just stick -m64/-m32 on your command line and test the other type of size_t. Even if you're on windows, and don't have the 64-bit toolchain set up, you will get all these errors from semantic. |
Copyright © 1999-2021 by the D Language Foundation