Attachment 75573 Details for Bug 199152 – A file with a class definition and complete bug description in its comments

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

A file with a class definition and complete bug description in its comments

EclipseFormatterBug.java (text/plain), 3.32 KB, created by Lorenzo Donati

on 2007-08-07 15:19:25 EDT

(hide)

Description:

Filename:

MIME Type:

Creator: Lorenzo Donati

Created: 2007-08-07 15:19:25 EDT

Size: 3.32 KB

patch

obsolete

>package formatterbug;
>
>@SuppressWarnings( { "all", "synthetic-access" })
>public class EclipseFormatterBug {
>
>	/*
>	 * Format this file with Eclipse Java formatter with
>	 * following settings: default eclipse settings (eclipse
>	 * built-in formatter) plus 68 line width for code and
>	 * (plus 60 for comments, but I used that just to make
>	 * these comments more readable).
>	 */
>
>	public static void main(String[] args) {
>		Object aVeryLongArgumentTriggeringABugInEclipseFormatter = null;
>		someVeryLongMethodNameHavingJustOneArgument(aVeryLongArgumentTriggeringABugInEclipseFormatter);
>
>		/*
>		 * I would have expected the previous call would
>		 * have been wrapped like this:
>		 */
>		/*- 
>		 * someVeryLongMethodNameHavingJustOneArgument(
>		 *      aVeryLongArgumentExpression);
>		 */
>		/*
>		 * But it wasn't. It must be a bug, I guess, because
>		 * adding just one more argument makes everything
>		 * OK, even with shorter code lines like the
>		 * following.
>		 */
>		Object aNotSoLongArgument = null;
>		someVeryLongMethodNameHavingTwoArguments(
>				aNotSoLongArgument, null);
>		/*
>		 * Moreover, this behaviour doesn't seem to depend
>		 * on unsuitable formatter settings, since I could
>		 * not find a wrap settings combination that would
>		 * format the two lines consistently, that is
>		 * wrapping both or none (as I guess it should do,
>		 * if I'm not missing something). For example, the
>		 * same incosistent behaviour happens when setting
>		 * "Always wrap first element, others when
>		 * necessary" as the wrapping policy for function
>		 * calls.
>		 */
>
>		/*-
>		 * BTW: The same happens with qualified invocations
>		 * like the following (which are more common and for
>		 * which I actually found the possible bug). I
>		 * assume that I want the formatter NOT to split the
>		 * invocation at dots, because I prefer a style
>		 * where wrapping arguments take precedence over
>		 * wrapping qualified names. 
>		 * 
>		 * Anyway, it seems to me
>		 * that when there is just one argument, the
>		 * wrapping algorithm stops working correctly and
>		 * let that argument 'stick' to the left
>		 * parenthesis even if it should be wrapped.
>		 */
>
>		/* wrongly wrapped (and still too long) */
>		someField
>				.someMethodWithQuiteALongName(aVeryLongArgumentTriggeringABugInEclipseFormatter);
>		/* which should have been wrapped like this: */
>		/*-
>		 * someField.someMethodWithQuiteALongName(
>		 * 		aVeryLongArgumentTriggeringABugInEclipseFormatter);
>		 */
>
>		/* correctly wrapped when there are two or more args */
>		someField.someMethodWithQuiteALongName(aNotSoLongArgument,
>				null);
>	}
>
>	/*
>	 * What follows are just definitions to write the code
>	 * above. Irrelevant otherwise.
>	 */
>
>	private static void someVeryLongMethodNameHavingJustOneArgument(
>			Object veryLongArgumentExpression) {
>		/* EMPTY */
>	}
>
>	private static void someVeryLongMethodNameHavingTwoArguments(
>			Object veryLongArgumentExpression, Object object) {
>		/* EMPTY */
>	}
>
>	private static InnerClass someField = new InnerClass();
>
>	private static class InnerClass {
>
>		private static final String SOME_CONSTANT = null;
>
>		public void someMethodWithQuiteALongName(Object dummy) {
>			/* EMPTY */
>		}
>
>		public void someMethodWithQuiteALongName(
>				Object notSoLongArgument, Object object) {
>			/* EMPTY */
>		}
>	}
>
>}

Actions: View

Attachments on bug 199152: 75573