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 -~----------~----~----~----~------~----~------~--~---
