Hi David, To add to what I wrote earlier, the design of the Swift is such that adding new features isn’t “hard”, but it does require time and patience because most new features have ripple effects on other parts of the compiler that need to be thought through. Fortunately, the design of the compiler is such that vast majority of those ripple effects will cause a compile time failure. This is why I encouraged you to add new “.def” nodes up front. That’s the good news. The bad news is that you still need to think through the ripple effects and that means developing some minimal design and debugging expertise over the compiler as a whole. If you’re not discouraged by the process, the experience is quite rewarding.
One more tip: if you’re going to add a new language feature, focus first on the type system and writing tests. Once you feel that implications are fully thought through, you can move on to “code gen” (i.e. SILGen and IRGen). If you rush to “code gen” first so that you can play with your shiny new feature, then you’re likely to get frustrated by self-inflicted bugs. You can experience the blissful pre-code-gen world by invoking swift like so: swift -frontend -typecheck file.swift Dave > On Aug 29, 2017, at 17:26, David Sweeris <daveswee...@mac.com> wrote: > > I was thinking I'd probably eventually need to muck about with those, but > it's good to know that I should start poking around in there sooner rather > than later. Thanks! > >> On Aug 29, 2017, at 11:21 AM, David Zarzycki <zarzy...@icloud.com >> <mailto:zarzy...@icloud.com>> wrote: >> >> Hi David, >> >> You’re arguably deep in the weeds. Try starting by adding new nodes to >> ExprNodes.def and DeclNodes.def and watch what blows up. Once you do that, >> crib code similar nodes to get your new Expr/Decl nodes to start compiling. >> >> Please also keep in mind that LLVM and derived projects like Swift have >> custom RTTI logic (which is partly why these “.defs” files exist), and >> therefore language features like multiple inheritance don’t “just work” like >> you might expect. >> >> Dave >> >> >>> On Aug 29, 2017, at 14:04, David Sweeris via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> Hi everyone! I'm trying to implement literal values as generic types. So >>> far, I've made `LiteralExpr` inherit from both `Expr` and `GenericTypeDecl` >>> (instead of just `Expr`), and did whatever other changes were necessary to >>> get that compiling (mostly putting several "using Expr::setImplicit;" kind >>> of lines within `LiteralExpr`'s declaration and prepending "(Expr*)" to a >>> bunch of variables in what are now ambiguous function calls). >>> >>> Anyway, I haven't done any testing yet to see how much I've broken >>> (compiles != works), but before I get neck-deep in everything I thought I'd >>> ask if anyone sees any fundamental issues with this approach, or has any >>> better ideas. >>> >>> - Dave Sweeris >>> _______________________________________________ >>> swift-dev mailing list >>> swift-dev@swift.org <mailto:swift-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-dev >>> <https://lists.swift.org/mailman/listinfo/swift-dev> >> >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
