Community
Participate
Working Groups
We can be smarter here - If an option is changed from error to warning, we should simply convert the corresponding error markers to warning markers. - Similarly for changing an option from warning to error - If an option is changed from error/warning to ignore, the corresponding markers can simply be deleted So the only case a build should happen is if an option is changed from ignore to error/warning.
The build is triggered in org.eclipse.jdt.internal.ui.preferences. OptionsConfigurationBlock.processChanges(IWorkbenchPreferenceContainer). For workspace option changes, this becomes quite complicated, since their effect depends on whether we have project-specific settings or not. Even for project-specific options, it's not trivial. Some of the options have dependencies on other options, and the added smartness needs to take this into account. I don't want to duplicate all these dependencies in the UI code. The only options we could consider are the Ignore/Warning/Error options. > - If an option is changed from error/warning to ignore, the corresponding > markers can simply be deleted We have to check carefully whether that's really true for all options. Might not be the case for e.g. the SuppressWarnings options. Furthermore, we would have to be sure that the compiler doesn't suppress any warnings when it encounters an error in the vicinity.
Maybe this could be delegated to JDT Core?
