Am Mittwoch, dem 22.07.2026 um 10:16 +0200 schrieb Richard Biener: > On Wed, Jul 22, 2026 at 9:31 AM Jakub Jelinek <[email protected]> wrote: > > > > On Wed, Jul 22, 2026 at 09:06:58AM +0200, Richard Biener wrote: > > > That said, I also believe trying to get tree more strongly typed using C++ > > > is not going to be an improvement. That might be the fault of C++ though. > > > > > > Possibly doing sth like > > > > > > extern tree fold_build2_loc (location_t, enum tree_code, tree_type, tree, > > > tree CXX_MEM_STAT_INFO); > > > > > > with checking-enabled tree_type expanding to assertion (but otherwise just > > > being a no-op wrapper), and possibly allowing type assertions and/or > > > automatic annotation for static analysis might be an improvement? > > > > Usually something inside of fold_build2_loc actually accesses some > > properties of the type and type checking triggers there. So, by moving > > that check earlier, all we'd achieve is to assert one or two frames up > > in the callstack.
I agree that run-time checking the dynamic downcast is only marginally useful. What would be more useful would be the static check that ensures that a tree_expr cannot be passed to a function expecting a tree_type. Still, the main benefit for me would not be static / run-time checking but the self-documenting nature of the types in the source code. I would also see a real benefit also if tree types were to properly maintain their invariants. Currently, there are a lot of implicit assumptions mixed with some incomplete explicit testing done in verify_type etc., but doing this more systematically by properly encapsulating the trees in subtypes with an API that ensures that the invariants are maintained (instead of checking them occasionally) would be helpful. Because now, if I add something to c_verify_type because I notice that some part of the C FE implicit assumes this property, I always encounter some new corner cases where this assumption is actually violated. > > With types vs. non-types, there is also the complication what is > > error_mark_node, currently we treat it as both expression and type, but > > with limited usability, TREE_TYPE (error_mark_node) is error_mark_node. > > I think I was suggesting to have ERROR_TYPE/error_type_node at some > point. That would > be a requirement for any of this. It would also avoid some ice-on-invalid > where type accessors are used on error_mark_node without a prior > check for this case (but possibly only delay those). The issue with errors is also that it not really clear in what context an error_mark_node is allowed and where not. This is also something where static type checking could help. Martin > > Richard. > > > > > Jakub > >
