Community

bearophile schrieb:
> Walter:
>
>> Only because clang made a marketing issue out of it. Nobody coming from dmc++
>> noticed.
>>
>> I used to point out this feature in dmc++ to users. Nobody cared, I'd just get
>> blank looks. Why would I drop it if people wanted it?
>
> Maybe it's all just marketing. But sometimes marketing is also a form of education, it teaches people a new way to do something, or why they should care about something.
>
> Another possibity is that maybe the ecosystem around a language is changed, today more people use an IDE (especially people that don't use C/C++), and if you are using an IDE then maybe it is an useful feature.
>
> Probably reality is a mix of those different possibilities.
>
>
>> Clang did have a nice idea with the spelling corrector. I implemented it in dmc
>> and dmd, and got flak for "wasting time" by adding it. I still like it, though,
>> and think it's an improvement :-)
>
> In my opinion too it's an improvement. I presume some people have said it was a "waste of time" because currently there are more important issues/bugs in DMD.
>
>
> In the meantime I have underlined a second small idea from Clang that I think will be useful to implement in D/DMD too, the use of "aka", this is an example from Clang:
>
> t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a
> structure or union
>
>
> This is a wrong D2 program:
>
>
> void main() {
> alias int Foo;
> Foo f;
> f = f.x;
> }
>
>
> DMD 2.049 prints:
> test.d(4): Error: no property 'x' for type 'int'
>
> But a more useful error message may be:
> test.d(4): Error: no property 'x' for type 'Foo' (aka 'int')
>
> In a tiny program like that the difference doesn't show much, but as programs get bigger, and alias is more far from its usage, it will be useful.
>
> The enhancement request:
> http://d.puremagic.com/issues/show_bug.cgi?id=5004
>
> Bye,
> bearophile
It's not just the aka that would be really helpful here, but especially the "type Foo" instead of
"type int".
Sometimes you have aliased types you use without really thinking too much about their real type,
like FILE, socket_t and stuff like that.
So when you get an error-message talking about int or something and your code says socket_t it may
be harder to find the error - especially when you have got multiple variables of different types in
one line.
Of course getting information about types (the "logical" type like socket_t and the original type
like int) in the error-message like in bearophiles "aka" suggestion would be the best solution :)

On 10/26/10 9:07 CDT, Leandro Lucarella wrote:
> Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:
>> On 26.10.2010 7:42, Walter Bright wrote:
>>> Rainer Deyke wrote:
>>>> On 10/25/2010 19:01, Walter Bright wrote:
>>>>> Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
>>>>> and NOBODY CARES.
>>>>> Not one person in 25 years has ever even commented on it. Nobody
>>>>> commented on its lack in dmd.
>>>>
>>>> I think someone just did.
>>>
>>> Only because clang made a marketing issue out of it. Nobody coming
>> >from dmc++ noticed.
>>>
>>> I used to point out this feature in dmc++ to users. Nobody cared,
>>> I'd just get blank looks. Why would I drop it if people wanted it?
>>>
>>> Clang did have a nice idea with the spelling corrector. I
>>> implemented it in dmc and dmd, and got flak for "wasting time" by
>>> adding it. I still like it, though, and think it's an improvement
>>> :-)
>> I actually like this spell-checking thing. It was of great help to
>> me, especially while I was just learning D, all those new funny
>> function names...
>
> I'm looking to you, Andrei!!!
I'm ducking.
Andrei

Jacob Carlborg wrote:
> That is what the whole thread is about, giving better and more accurate
> error messages. A great example, as bearophile shows, is the missing
> semicolon error which Clang points to the "right" line wheres DMD, GCC
> points to the start of the next statement. As Walter points out this is
> syntactical correct since there is no correct position for the semicolon
> in a whitespace indepdent language but I still think bearophile is
> correct in this case.
>
Of course, with C it is even worse since the place gcc points to
may not even be in the right *file*...
Jerome
--
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jérôme M. Berger wrote:
> Walter Bright wrote:
>> bearophile wrote:
>>>> "acts very badly" kinda means the same thing :-)
>>> DMD acts very badly regarding that specific situation,
>> As I said, the two error messages it gives are right on target.
>
> "AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
> 'mtype.c'" is "right on target" when compiling a D source file?? I'd
> hate to see a message you consider bad ;)
As I also said, that was a compiler bug, and I was referring to the two
diagnostic messages preceding it.

Walter Bright wrote:
> Jérôme M. Berger wrote:
>> Walter Bright wrote:
>>> bearophile wrote:
>>>>> "acts very badly" kinda means the same thing :-)
>>>> DMD acts very badly regarding that specific situation,
>>> As I said, the two error messages it gives are right on target.
>>
>> "AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
>> 'mtype.c'" is "right on target" when compiling a D source file?? I'd
>> hate to see a message you consider bad ;)
>
> As I also said, that was a compiler bug, and I was referring to the two
> diagnostic messages preceding it.
Yes, but I believe that the reason bearophile said "acts very
badly" is because of the assert, since the other two messages are
more or less the same as the clang message (albeit slightly more
verbose).
Jerome
--
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jérôme M. Berger wrote:
> Walter Bright wrote:
>> Jérôme M. Berger wrote:
>>> Walter Bright wrote:
>>>> bearophile wrote:
>>>>>> "acts very badly" kinda means the same thing :-)
>>>>> DMD acts very badly regarding that specific situation,
>>>> As I said, the two error messages it gives are right on target.
>>> "AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
>>> 'mtype.c'" is "right on target" when compiling a D source file?? I'd
>>> hate to see a message you consider bad ;)
>> As I also said, that was a compiler bug, and I was referring to the two
>> diagnostic messages preceding it.
>
> Yes, but I believe that the reason bearophile said "acts very
> badly" is because of the assert, since the other two messages are
> more or less the same as the clang message (albeit slightly more
> verbose).
I don't agree, as the thread is about quality of error messages, not bugs in the
compiler.

On 2010-10-25 22:21:01 -0400, bearophile <bearophileHUGS@lycos.com> said:
> Michel Fortin:
>
>> I'd like it very much if dmd printed the column number
>> for the caret in addition to the line.
>
> The C# compiler too show those column number. But last time Walter has
> explained that to do this, the compiler has to keep more data (all
> those line numbers), so this may slow down the compilation a little.
> And of course currently this information is not present, so it probably
> requires a good amount of changes to be implemented.
It's not that hard to implement. I did a custom version of the DMD
frontend to do something similar for the early versions of D for Xcode.
I needed to have the exact start and end location of each token
expressed in character index from the beginning of the file. I used
that for syntax highlighting.
To get column numbers in error messages, here's all I'd expect you need to do:
1. add a column field to the Loc struct (in mars.h)
2. make the lexer keep track of the current column
3. make error() print that field
Give it a try if you want.
Then you can do some benchmark to check how slower it is (probably
nothing noticeable).
--
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 26/10/2010 04:32, Walter Bright wrote:
> bearophile wrote:
>> The C# compiler too show those column number. But last time Walter has
>> explained that to do this, the compiler has to keep more data (all
>> those line
>> numbers), so this may slow down the compilation a little. And of course
>> currently this information is not present, so it probably requires a good
>> amount of changes to be implemented. The slowdown problem may be
>> solved as in
>> GCC, adding a compilation switch that gives/removes the column number (it
>> uses to be switched off on default, now after the competition by Clang
>> it's
>> switched on on default).
>
> Switching it off will have no effect on compile speed.
>
Why is that? What would cause a loss in compile speed even if this
option was turned off?
--
Bruno Medeiros - Software Engineer