STM32CubeIDE Fehler beim Speichern

Funktioniert es über Menüaufruf:

Source -> Format

?

Nein, dann formatiert er nicht. Genauso wenig bei Strg+Shift+f.
Bei beiden erscheint dann im View "Error Log" die Meldung "Unhandled 
event loop exception", im Detail dann wieder
java.lang.UnsupportedOperationException
  at java.base/java.util.AbstractList.add(AbstractList.java:153)
  at java.base/java.util.AbstractList.add(AbstractList.java:111)
        ...

Aber nur in main.c! Aber es scheint dann also ein Problem des Formatters 
zu sein. Interessant.

Es liegt wohl an meiner persönlichen Formatter-Konfiguration. Nehme ich 
wieder den Standard Formatter K&R, gibt es keinen Fehler. Nach Klasse.

Schnauze voll: Nachdem ich wieder zu meinem Formattereinstellungen 
zurück bin, kommt jetzt beim Formatieren plötzlich die Meldung

Unhandled event loop exception:

java.lang.IllegalArgumentException: offset or length outside of string. 
offset: 0, length: 5978, string size: 5830
  at 
org.eclipse.cdt.internal.corext.util.CodeFormatterUtil.format(CodeFormat 
terUtil.java:124)
  at 
org.eclipse.cdt.internal.ui.text.CFormattingStrategy.format(CFormattingS 
trategy.java:72)

Ich gehe jetzt lieber zum Sport und laß für heute meine Energie dort...

Welche Java Version benutzt Du?
Bei mir läuft es mit:
java.vm.vendor=AdoptOpenJDK
java.vm.version=11.0.11+9
jdk.debug=release

Sonst bleibt mMn nur noch ein "Böses" Sonderzeichen in der main.c .
Hast Du mal eine komplett neue main.c probiert?

Frisch erschöpft vom Sport zurück ;-)

Wenn ich die main.c umbenenne in z.B. maino.co, kann ich die Datei 
fehlerfrei speichern (und im Hintergrund natürlich formatieren). Damit 
schließe ich die Sonderzeichentheorie aus.

Wo ich die Java-Version rausbekomme, weiß ich nicht. Aber m.W. liefert 
ST (wie NXP bei MCUXPresso usw. auch) das ganze Javazeugs mit, damit 
definierte Zustände herrschen.

Ist irgendwie schon schräg, daß das nur bei der Datei main.c auftritt 
bzw. wenn die Datei so heißt.

Ich konnte das Problem bis hierher reduzieren:

java.lang.IllegalArgumentException: offset or length outside of string. 
offset: 0, length: 4740, string size: 4620
  at 
org.eclipse.cdt.internal.corext.util.CodeFormatterUtil.format(CodeFormat 
terUtil.java:124)

Das kommt von dieser Methode:

1

/**

2

 * Creates edits that describe how to format the given string. Returns <code>null</code> if the code could not be formatted for the given kind.

3

 * @throws IllegalArgumentException If the offset and length are not inside the string, a

4

 *  IllegalArgumentException is thrown.

5

 */

6

public static TextEdit format(int kind, String string, int offset, int length, int indentationLevel, String lineSeparator, Map options) {

7

  if (offset < 0 || length < 0 || offset + length > string.length()) {

8

    throw new IllegalArgumentException("offset or length outside of string. offset: " + offset + ", length: " + length + ", string size: " + string.length());   //$NON-NLS-1$//$NON-NLS-2$//$NON-NLS-3$

9

  }

10

  return ToolFactory.createCodeFormatter(options).format(kind, string, offset, length, indentationLevel, lineSeparator);

11

}

offset + length > string.length()

Wenn ich mit #ifdef ausgegraute Teile in der zu formatierenden Datei 
lösche, ist der Fehler weg. Also ist irgendwie das Problem, daß 
irgendein Teil in Eclipse den ausgegrauten Teil falsch interpretiert.
Und spätestens da hört es für mich leider auf...
Irgendjemand eine Idee, wie/wo ich da weitermachen muß?

Ich konnte es soweit eindampfen: Es scheint mit meiner persönlichen 
Formatter-Datei zusammenzuhängen. Das Problem tritt nur auf, wenn durch 
Präprozessordirektiven etwas inaktiviert (ausgegraut) wird.

Unhandled event loop exception

java.lang.UnsupportedOperationException
  at java.base/java.util.AbstractList.add(AbstractList.java:153)
  at java.base/java.util.AbstractList.add(AbstractList.java:111)
  at 
java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:35 
2)
  at 
org.eclipse.cdt.internal.formatter.CodeFormatterVisitor.format(CodeForma 
tterVisitor.java:490)
  at 
org.eclipse.cdt.internal.formatter.CCodeFormatter.formatRegions(CCodeFor 
matter.java:209)
  at 
org.eclipse.cdt.internal.formatter.CCodeFormatter.format(CCodeFormatter. 
java:174)
...

Da ich von Java leider keine Ahnung habe, komme ich hier nicht weiter. 
Zumindest die exakte Stelle konnte ich finden:

In CodeFormatterVisitor.java

1

448  private List<InactivePosition> fInactivePreprocessorPositions;

2

...

3

490  inactive.addAll(fInactivePreprocessorPositions);

In Zeile 490 soll es ja crashen. Vielleicht kann ein Javaist damit was 
anfangen...

Die Definition in Zeile 489 wird vermutlich auch wichtig sein:

1

448  private List<InactivePosition> fInactivePreprocessorPositions;

2

...

3

489  List<InactivePosition> inactive = collectNoFormatCodePositions(unit);

4

490  inactive.addAll(fInactivePreprocessorPositions);

Niklas G. schrieb:
> Klingt doch stark nach einem Bug in CDT. Vielleicht mit der den Fehler
> verursachenden Datei als Bug melden?
>
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT

Der Fix inkl. temporärem Workaround hat dann nur 2 Stunden nach Meldung 
gedauert. Bin tiefst beeindruckt!!!

Statt

1

return Collections.emptyList();

an 2 Stellen in 
core/org.eclipse.cdt.core/src/org/eclipse/cdt/internal/formatter/CodeFor 
matterVisitor.java  (allerdings Zeile 4939 + 4943)

1

return new ArrayList<>();