| Message ID | 5277CF30.1080909@oracle.com |
|---|---|
| State | New |
| Headers | show |
Surely it should be valid to allocate a Java boolean type. Andrew, how should that work? Jason
On 11/04/2013 05:21 PM, Jason Merrill wrote: > Surely it should be valid to allocate a Java boolean type. Andrew, > how should that work? It's not allowed. All objects that are allocated by new must be of class type (i.e. instances of a subclass of java.lang.Object), but boolean is a primitive type. Andrew.
On 11/06/2013 05:42 AM, Andrew Haley wrote: > On 11/04/2013 05:21 PM, Jason Merrill wrote: >> Surely it should be valid to allocate a Java boolean type. Andrew, >> how should that work? > > It's not allowed. All objects that are allocated by new must be of > class type (i.e. instances of a subclass of java.lang.Object), but > boolean is a primitive type. In that case, Paolo's first patch is OK. Jason
Index: cp/init.c =================================================================== --- cp/init.c (revision 204353) +++ cp/init.c (working copy) @@ -2461,9 +2461,16 @@ build_new_1 (vec<tree, va_gc> **placement, tree ty if (vec_safe_is_empty (*placement) && TYPE_FOR_JAVA (elt_type)) { tree class_addr; - tree class_decl = build_java_class_ref (elt_type); + tree class_decl; static const char alloc_name[] = "_Jv_AllocObject"; + if (!MAYBE_CLASS_TYPE_P (elt_type)) + { + error ("%qT isn%'t a valid Java class type", elt_type); + return error_mark_node; + } + + class_decl = build_java_class_ref (elt_type); if (class_decl == error_mark_node) return error_mark_node; Index: testsuite/g++.dg/other/java3.C =================================================================== --- testsuite/g++.dg/other/java3.C (revision 0) +++ testsuite/g++.dg/other/java3.C (working copy) @@ -0,0 +1,7 @@ +// PR c++/11006 + +typedef int* jclass; + +void foo () { + new __java_boolean; // { dg-error "valid" } +}
Hi, we have got this very old bug, where we ICE in build_java_class_ref because TYPE is an INTEGER_TYPE and we try to use TYPE_FIELDS on it. Shall we apply something like the below and resolve it for good? Alternately, we could maybe provide the same message we currently provide in release-builds, when we get to: if (!field) { error ("can%'t find %<class$%> in %qT", type); return error_mark_node; } Thanks! Paolo. //////////////////////