[gcjx] Patch: FYI: update PROJECTS et al

[gcjx] Patch: FYI: update PROJECTS et al

[Tom Tromey]

I'm checking this in on the gcjx branch.

This updates some of the surrounding internal documentation a bit.

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>
	* TODO: Updated.
	* PROJECTS: Updated.
	* HACKING: New file.

Index: HACKING
===================================================================
--- HACKING	(revision 0)
+++ HACKING	(revision 0)
@@ -0,0 +1,76 @@
+This file explains the source layout of gcjx, and some of the rules
+for developing it.
+
+================================================================
+== Hacking stuff
+
+gcjx uses the GNU C style extended to C++
+
+Use assert() liberally.  abort() in unrecoverable situations.  (We
+should probably have a nice wrapper for abort so that it shows up in
+Jacks logs.)
+
+
+================================================================
+== Source Code Road Map
+
+Anything in model/ is related to the model of the program.  For the
+most part things are self-explanatory, e.g., model_assert is the class
+that models the "assert" statement.  Classes in this directory
+starting with "I" are interface classes and are ordinarily used as
+"mixins".
+
+semantic analysis:
+ - maybe move this code to new analyze/ directory?
+    access.hh
+    conversions.hh
+    defassign.hh
+    fold.hh
+    name.hh
+    resolve.hh
+    scope.hh
+
+class reading and writing:
+    everything in bytecode/
+
+parsing and lexing:
+    everything in source/
+
+helpers, utility code, etc:
+    buffer.hh
+    classcache.hh
+    directory.hh
+    location.hh
+    owner.hh
+    typedefs.hh
+    util.hh
+    watch.hh
+
+general compiler framework:
+    compiler.hh
+    exception.hh
+    factory.hh
+    global.hh
+    visitor.hh
+
+code for helping ahead-of-time compilers:
+    everything in aot/
+
+A model_foo is a class in the model.  We use `model_' and not
+`model::' because we want simple names like "while", which are C++
+keywords.
+
+A ref_foo is an owner<model_foo>.  Not every model class needs a ref
+class.  If model_y is a subclass of model_x, then a ref_y can be
+assigned to a ref_x -- owner<> understands this.
+
+Ownership of model objects must be considered carefully.  If there is
+a natural container for something, it should usually be the owner.
+E.g., a class owns its members, but a class does not own its
+superclass or interfaces.  Represent ownership with a ref_ and
+otherwise with a pointer to a model_.
+
+Right now we have some goofy things in the model where we have fields
+based on implementation, e.g. deprecation is represented with a
+javadoc object.  This is incorrect, deprecation should be represented
+with a flag and then settor should handle conversion.
Index: PROJECTS
===================================================================
--- PROJECTS	(revision 107604)
+++ PROJECTS	(working copy)
@@ -16,17 +16,13 @@
 Annotations have been started but not finished
 - handling package-info.java
   and give warnings if a class appears in that file
-- package parsing buglet in parse::compilation_unit()
 - non-circularity of annotations
 - where should model_package call resolve_annotations ?
 
-enums partly work.  They are completely untested but much of the code
-is there.  some code generation work remains.  a little semantic
-analysis work remains, including missing error checking
+enums mostly work.  Generics mostly work.  For both of these we need a
+number of error checks at the very least; there are some lurking bugs
+too.
 
-Generics partly work.  Generic methods have not been implemented at
-all.
-
 varargs, boxing, and unboxing work.  however there are a couple of
 cases of {un,}boxing conversion that still don't work; see TODO
 code generation for boxing/unboxing with foreach doesn't work.
@@ -36,29 +32,23 @@
 ================================================================
 == Parser
 
-The parser probably has performance problems.  Error handling and
-recovery is quite weak.
+The parser has performance problems.  Error handling and recovery is
+quite weak.
 
+there's a package parsing buglet in parse::compilation_unit()
+
 we don't handle attributes correctly
 they can be intermixed with modifiers
 
-it is possible to explicitly pass the type arguments to a generic
-method invocation.  we mostly handle this but there is one remaining
-case in the parser.  the model parts haven't been finished yet.  see
-parse::primary().  in the model we need to have a new virtual method
-for handling genericization, with the default doing type inference
 
-
 ================================================================
 == Semantic Analysis
 
-static import works, but the internal APIs are broken and we don't do
-the error checking we ought to do.
-
 There's some ugliness in Iname; perhaps this interface should be
 entirely removed.
 
 The code in name.cc is fairly inefficient for the most part.
+(But it doesn't show up in profiles)
 
 classify_ambiguous_name needs to be written.  Perhaps it should be
 called classify_expression_name, as that is more correct.
@@ -68,7 +58,10 @@
 capture cases that are incorrect.  static context handling still
 doesn't really work.
 
+there are some remaining definite assignment bugs; look through
+jacks results to see
 
+
 ================================================================
 == Class Reading
 
@@ -180,75 +173,3 @@
 
 it turns out that parsing can affect global state by creating packages
 we need a lock somewhere to deal with this
-
-
-================================================================
-== Source Code Road Map
-
-Anything in model/ is related to the model of the program.  For the
-most part things are self-explanatory, e.g., model_assert is the class
-that models the "assert" statement.  Classes in this directory
-starting with "I" are interface classes and are ordinarily used as
-"mixins".
-
-semantic analysis:
- - maybe move this code to new analyze/ directory?
-    access.hh
-    conversions.hh
-    defassign.hh
-    fold.hh
-    name.hh
-    resolve.hh
-    scope.hh
-
-class reading and writing:
-    everything in bytecode/
-
-parsing and lexing:
-    everything in source/
-
-helpers, utility code, etc:
-    buffer.hh
-    classcache.hh
-    directory.hh
-    location.hh
-    owner.hh
-    typedefs.hh
-    util.hh
-    watch.hh
-
-general compiler framework:
-    compiler.hh
-    exception.hh
-    factory.hh
-    global.hh
-    visitor.hh
-
-code for helping ahead-of-time compilers:
-    everything in aot/
-
-if we write threading code, put in thread/; see bkoz's libthread++
-and also thread-local extension class.
-
-A model_foo is a class in the model.  We use `model_' and not
-`model::' because we want simple names like "while", which are C++
-keywords.
-
-A ref_foo is an owner<model_foo>.  Not every model class needs a ref
-class.  If model_y is a subclass of model_x, then a ref_y can be
-assigned to a ref_x -- owner<> understands this.
-
-Ownership of model objects must be considered carefully.  If there is
-a natural container for something, it should usually be the owner.
-E.g., a class owns its members, but a class does not own its
-superclass or interfaces.  Represent ownership with a ref_ and
-otherwise with a pointer to a model_.
-
-Right now we have some goofy things in the model where we have fields
-based on implementation, e.g. deprecation is represented with a
-javadoc object.  This is incorrect, deprecation should be represented
-with a flag and then settor should handle conversion.
-
-Use assert() liberally.  abort() in unrecoverable situations.  (We
-should probably have a nice wrapper for abort so that it shows up in
-Jacks logs.)
Index: TODO
===================================================================
--- TODO	(revision 108811)
+++ TODO	(working copy)
@@ -16,6 +16,10 @@
 class read from .class
 even though we technically don't need to resolve them all (arguably)
 this results in a build failure
+one approach here is that for classes which we won't be fully compiling,
+we can do partial inheritance of members, based on name
+if we made this virtual we could lazily instantiate members of generic
+paramerizations -- a bonus
 
 right now we use std::cerr liberally
 instead we should define a simple 'emit a string' interface
@@ -23,11 +27,6 @@
 the default could still write to stderr
 but this would let users intercept and redirect output
 
-Tom F. suggested a HACKING file explaining some of
-the source layout stuff and other gcjx rules,
-eg where headers are included
-populate with the last section from PROJECTS
-
 right now we exit after the first semantic analysis error
 this is unfriendly to say the least
 we should fix up and continue on somehow

Re: [gcjx] Patch: FYI: update PROJECTS et al

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

| I'm checking this in on the gcjx branch.

Thanks!

-- Gaby