Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but I've also seen this trying to understand the general compiler changes that are happening in trunk gwt - is the CompilerContext really an essential part of ModuleDefLoader in general? From what I can see it is tracked as a local variable, but only used in the enforceStrictResources() check, which could just as easily be a boolean. For any synthetic module (which can't have any resources at all), this is a moot point so the context could be skipped entirely, and more generally it *seems* to just be a flag.
CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and passes it to the JdtCompiler, which doesn't actually use it at all - that seems to be the extent of its use when you do a ModuleDef.getCompilationState (which now requires that context as an argument, even though the ModuleDef already should have that state from the previously mentioned ModuleDefLoader?). Precompile takes it to get the module and the options (instead of taking the module and the options), and the J2JSCompiler takes it just to read options. At least as of 2.6 branch, haven't done the same tracing through master just yet. So my question is two-fold: Is this the new way of avoiding too many sets of config types to track, and if so, why restore the old APIs so that the designer can use them in 2.6.1 instead of updating the designer to generate a simple context for its own needs? Assuming this is the future way of dealing with options/etc, won't the designer just break again as this becomes more and more necessary to hook into the compiler from outside? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
