Clang - An Open Source C/C++ Compiler Front End

Douglas Gregor | 1 Feb 2012 16:56

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Jan 31, 2012, at 10:25 PM, Ted Kremenek wrote:

On Jan 31, 2012, at 8:21 PM, Douglas Gregor wrote:

It seems nice to distinguish in the text where the actual text comes from. That said, it just seems nice-to-have, not super important.

Certainly "#error" seems like a pretty lame way to do this. ;] My initial thought would be:

foo.cc:42:13: error: (from source directive) this code requires widget to be defined

or some variant thereof.

That seems even more verbose, and not any more clearer.

Among other nice things is that then the message is the same between #error and #warning, and only the level changes. The downside I see is that it's more verbose.

That's a step up from "#error", but I still find it unnecessary.

We can always support another command line flag that causes us to omit the '#error' and the '#warning' in the message for clients that don't want it (which do exist) since they can use diagnostic categories. That may seem like overkill, but we have plenty of driver flags for controlling the behavior of diagnostics. The suggestion of having "from source directive" is just a poor man's replacement of not having good diagnostic categories on the command line (where they make less sense).

We shouldn't be introducing a flag to control a minor aspect of two related diagnostics.

- Doug

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Ted Kremenek | 1 Feb 2012 17:35

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Feb 1, 2012, at 7:56 AM, Douglas Gregor wrote:

On Jan 31, 2012, at 10:25 PM, Ted Kremenek wrote:

On Jan 31, 2012, at 8:21 PM, Douglas Gregor wrote:

It seems nice to distinguish in the text where the actual text comes from. That said, it just seems nice-to-have, not super important.

Certainly "#error" seems like a pretty lame way to do this. ;] My initial thought would be:

foo.cc:42:13: error: (from source directive) this code requires widget to be defined

or some variant thereof.

That seems even more verbose, and not any more clearer.

Among other nice things is that then the message is the same between #error and #warning, and only the level changes. The downside I see is that it's more verbose.

That's a step up from "#error", but I still find it unnecessary.

We can always support another command line flag that causes us to omit the '#error' and the '#warning' in the message for clients that don't want it (which do exist) since they can use diagnostic categories. That may seem like overkill, but we have plenty of driver flags for controlling the behavior of diagnostics. The suggestion of having "from source directive" is just a poor man's replacement of not having good diagnostic categories on the command line (where they make less sense).

We shouldn't be introducing a flag to control a minor aspect of two related diagnostics.

- Doug

Why? We have flags for controlling the depth of macro stacks in text diagnostics. How is this any different?

More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Douglas Gregor | 1 Feb 2012 17:46

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Feb 1, 2012, at 8:35 AM, Ted Kremenek wrote:

On Feb 1, 2012, at 7:56 AM, Douglas Gregor wrote:

On Jan 31, 2012, at 10:25 PM, Ted Kremenek wrote:

On Jan 31, 2012, at 8:21 PM, Douglas Gregor wrote:

It seems nice to distinguish in the text where the actual text comes from. That said, it just seems nice-to-have, not super important.

Certainly "#error" seems like a pretty lame way to do this. ;] My initial thought would be:

foo.cc:42:13: error: (from source directive) this code requires widget to be defined

or some variant thereof.

That seems even more verbose, and not any more clearer.

Among other nice things is that then the message is the same between #error and #warning, and only the level changes. The downside I see is that it's more verbose.

That's a step up from "#error", but I still find it unnecessary.

We can always support another command line flag that causes us to omit the '#error' and the '#warning' in the message for clients that don't want it (which do exist) since they can use diagnostic categories. That may seem like overkill, but we have plenty of driver flags for controlling the behavior of diagnostics. The suggestion of having "from source directive" is just a poor man's replacement of not having good diagnostic categories on the command line (where they make less sense).

We shouldn't be introducing a flag to control a minor aspect of two related diagnostics.

- Doug

Why? We have flags for controlling the depth of macro stacks in text diagnostics. How is this any different?

*That* is a general flag that affects every diagnostic Clang can emit. It controls a formatting policy.

What you're proposing is a flag that tweaks the wording of two specific diagnostics. It's too narrow in scope to warrant a special flag.

More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.

Options that control general policies (color, word-wrapping, macro/template depth, carets, Fix-Its, ranges) all make sense. Options that tweak the wording of specific diagnostics don't, because it's not a useful thing for a user to think about ("oh, I *would* like that diagnostic to have a slightly different wording. let me go modify my build settings…") and because this solution just doesn't scale if we start resolving "what's the best wording?" discussions by adding a flag.

- Doug

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Ted Kremenek | 1 Feb 2012 17:51

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Feb 1, 2012, at 8:46 AM, Douglas Gregor wrote:

*That* is a general flag that affects every diagnostic Clang can emit. It controls a formatting policy.

What you're proposing is a flag that tweaks the wording of two specific diagnostics. It's too narrow in scope to warrant a special flag.

More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.

Options that control general policies (color, word-wrapping, macro/template depth, carets, Fix-Its, ranges) all make sense. Options that tweak the wording of specific diagnostics don't, because it's not a useful thing for a user to think about ("oh, I *would* like that diagnostic to have a slightly different wording. let me go modify my build settings…") and because this solution just doesn't scale if we start resolving "what's the best wording?" discussions by adding a flag.

I agree in principle, but this isn't an academic problem. For clients (e.g., an IDE) that don't want to include the #error or #warning in the diagnostic, because they have diagnostic categories to show to user, what would you propose as the solution?

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Douglas Gregor | 1 Feb 2012 17:57

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Feb 1, 2012, at 8:51 AM, Ted Kremenek wrote:

On Feb 1, 2012, at 8:46 AM, Douglas Gregor wrote:

*That* is a general flag that affects every diagnostic Clang can emit. It controls a formatting policy.

What you're proposing is a flag that tweaks the wording of two specific diagnostics. It's too narrow in scope to warrant a special flag.

More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.

Options that control general policies (color, word-wrapping, macro/template depth, carets, Fix-Its, ranges) all make sense. Options that tweak the wording of specific diagnostics don't, because it's not a useful thing for a user to think about ("oh, I *would* like that diagnostic to have a slightly different wording. let me go modify my build settings…") and because this solution just doesn't scale if we start resolving "what's the best wording?" discussions by adding a flag.

I agree in principle, but this isn't an academic problem. For clients (e.g., an IDE) that don't want to include the #error or #warning in the diagnostic, because they have diagnostic categories to show to user, what would you propose as the solution?

My suggestion is to never include the #error or #warning, nor any text to explicitly stating that this diagnostic comes from a #warning or #error. It provides no value to any client that maps the error over to source code (whether it be through the caret diagnostics, range highlighting/jump-to-error in an IDE, or just plan looking at the line number). And I can't bring myself to care about clients that don't map the error over to source code, because this particular set of diagnostics is just the tip of the iceberg for those clients who willfully throw out all of the useful information we provide.

- Doug

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Chandler Carruth | 1 Feb 2012 18:10

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Wed, Feb 1, 2012 at 8:57 AM, Douglas Gregor <dgregor-2kanFRK1NckAvxtiuMwx3w@public.gmane.org> wrote:

My suggestion is to never include the #error or #warning, nor any text to explicitly stating that this diagnostic comes from a #warning or #error.

FWIW, at outset I was merely in the "nice to have" camp. Doug's arguments converted me easily to the "never include this extra text" side of things.

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Chris Lattner | 1 Feb 2012 20:53

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Feb 1, 2012, at 8:57 AM, Douglas Gregor wrote:

On Feb 1, 2012, at 8:51 AM, Ted Kremenek wrote:

On Feb 1, 2012, at 8:46 AM, Douglas Gregor wrote:

*That* is a general flag that affects every diagnostic Clang can emit. It controls a formatting policy.

What you're proposing is a flag that tweaks the wording of two specific diagnostics. It's too narrow in scope to warrant a special flag.

More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.

Options that control general policies (color, word-wrapping, macro/template depth, carets, Fix-Its, ranges) all make sense. Options that tweak the wording of specific diagnostics don't, because it's not a useful thing for a user to think about ("oh, I *would* like that diagnostic to have a slightly different wording. let me go modify my build settings…") and because this solution just doesn't scale if we start resolving "what's the best wording?" discussions by adding a flag.

I agree in principle, but this isn't an academic problem. For clients (e.g., an IDE) that don't want to include the #error or #warning in the diagnostic, because they have diagnostic categories to show to user, what would you propose as the solution?

My suggestion is to never include the #error or #warning, nor any text to explicitly stating that this diagnostic comes from a #warning or #error. It provides no value to any client that maps the error over to source code (whether it be through the caret diagnostics, range highlighting/jump-to-error in an IDE, or just plan looking at the line number). And I can't bring myself to care about clients that don't map the error over to source code, because this particular set of diagnostics is just the tip of the iceberg for those clients who willfully throw out all of the useful information we provide.

FWIW, I completely agree with Doug.

-Chris

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

headers

Ted Kremenek | 1 Feb 2012 23:39

Re: #error and #warning: why include "#error/#warning" in the diagnostic?

On Feb 1, 2012, at 11:53 AM, Chris Lattner wrote:

On Feb 1, 2012, at 8:57 AM, Douglas Gregor wrote:

On Feb 1, 2012, at 8:51 AM, Ted Kremenek wrote:

On Feb 1, 2012, at 8:46 AM, Douglas Gregor wrote:

*That* is a general flag that affects every diagnostic Clang can emit. It controls a formatting policy.

What you're proposing is a flag that tweaks the wording of two specific diagnostics. It's too narrow in scope to warrant a special flag.

More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.

Options that control general policies (color, word-wrapping, macro/template depth, carets, Fix-Its, ranges) all make sense. Options that tweak the wording of specific diagnostics don't, because it's not a useful thing for a user to think about ("oh, I *would* like that diagnostic to have a slightly different wording. let me go modify my build settings…") and because this solution just doesn't scale if we start resolving "what's the best wording?" discussions by adding a flag.

I agree in principle, but this isn't an academic problem. For clients (e.g., an IDE) that don't want to include the #error or #warning in the diagnostic, because they have diagnostic categories to show to user, what would you propose as the solution?

My suggestion is to never include the #error or #warning, nor any text to explicitly stating that this diagnostic comes from a #warning or #error. It provides no value to any client that maps the error over to source code (whether it be through the caret diagnostics, range highlighting/jump-to-error in an IDE, or just plan looking at the line number). And I can't bring myself to care about clients that don't map the error over to source code, because this particular set of diagnostics is just the tip of the iceberg for those clients who willfully throw out all of the useful information we provide.

FWIW, I completely agree with Doug.

As do I. I'll prepare a patch to make this change.

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev