Sounds like a maintenance problem! Time to refactor ? On Fri, Jan 30, 2009 at 1:14 AM, Scott Blum <sco...@google.com> wrote:
> Nobody understands GenerateJavaAST. We just hack on it until it does the > right thing. :) > > > On Thu, Jan 29, 2009 at 6:59 PM, Ray Cromwell <cromwell...@gmail.com>wrote: > >> >> I think it would be useful to, but on second look, there appear to be >> a number of different contexts in which JCastOperation is generated by >> the compiler, rather than present in the original source: >> >> 1) when converting JDT expressions involving generics >> 2) when type-tightening >> 3) when simplifying expressions >> 4) in MethodInliner when cloning parameters >> 5) when autoboxing (primitive casts) >> 6) when normalizing JSOs >> >> So it seems there are three classes of casts. Those authored by the >> user, those generated for generics due to type-erasure, and those >> generated during optimization. >> >> Scott, >> I gotcha now. I see obvious places to do this in >> processExpression(MessageSend x) and JExpression >> processExpression(FieldReference x), but due to my lack of JDT >> knowledge, I don't quite understand what's going on in the >> processExpression(QualifiedNameReference x) and >> processExpression(SingleNameReference x) routines, so I'm not sure if >> anything has to be done in those. If follow Bruce's suggestion and >> simply tag JCastOperations based on their reason for insertion, it >> seems conceptually simpler to remove those in a latter compiler pass, >> and avoid risking breaking GenerateJavaAST, which honestly is code in >> which I don't understand the specifics of a lot of what's going on. >> >> -Ray >> >> >> On Thu, Jan 29, 2009 at 1:56 PM, Bruce Johnson <br...@google.com> wrote: >> > I'm long since unfamiliar with the specifics of that code, but it seems >> like >> > designating a JCastOperation as "generated by the compiler" would be >> useful, >> > then during actual code generation, you'd just avoid emitting the >> runtime >> > cast code. >> > >> > On Thu, Jan 29, 2009 at 4:52 PM, Ray Cromwell <cromwell...@gmail.com> >> wrote: >> >> >> >> Scott, >> >> Do you mean the JMethodCall produced by >> >> CastNormalizer.ReplaceTypeChecksVisitor? I looked at doing this, but >> >> it seems by the time you get to this stage, you know longer can tell >> >> the difference between a cast inserted automatically because of >> >> generics, or a cast inserted by the programmer (from JDT >> >> CastExpression). I suppose an extra field could be added to >> >> JCastOperation to tell if it came from an automatically generated >> >> cast, but perhaps this is not what you were thinking of? >> >> >> >> >> >> -Ray >> >> >> >> >> >> On Thu, Jan 29, 2009 at 1:23 PM, Scott Blum <sco...@google.com> wrote: >> >> > On Thu, Jan 29, 2009 at 3:41 PM, Ray Cromwell <cromwell...@gmail.com >> > >> >> > wrote: >> >> >> >> >> >> If I add a check for an option, and make this routine a no-op, is it >> >> >> going to work, or break something? Alternatively, I can replace >> calls >> >> >> to canCastUnsafe/dynamicCast with no-ops further down in the >> >> >> processing and get rid of all casts. >> >> > >> >> > This is going to break stuff because the return type of the called >> >> > method >> >> > will be seen to be Object without the cast, which will destroy >> >> > TypeTightener's ability to optimize, and generally the AST won't be >> >> > valid >> >> > without it. What you would need to do is modify the JMethodCall >> being >> >> > produced to override the return type of the target JMethod given your >> >> > better >> >> > generic information. >> >> > Scott >> >> > >> >> > > >> >> > >> >> >> >> >> > >> > >> > > >> > >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
