kuilpd wrote: > We could, but I'm not sure if that's the most important question right now. > The whole BasicType concept is very C-like. There is no "unsigned long long" > basic type in swift (or pretty much any other language). While you could say > that the function returns the langauge's equivalent (same bit width and > signedness?) of the named C type, by doing that, and also encoding all of the > type promotion rules inside common code, you're basically hardcoding > everything that makes the swift type system unique (when it comes to numbers > at least). Maybe that's okay, but at that point, I'm wondering if there's any > point in using a non-C type system. > > OTOH, if we say that addition of two swift variables should behave "like in > swift", then I think all of the addition code (including type ranking, > promotion, and whatnot) needs to happen inside a plugin (because swift > doesn't have type promotion). At that point, the question of using > GetBasicType may become moot.
This is what I was thinking as well. On the one hand, we want DIL to produce the same expression results as the language it tries to emulate. So if there is some fundamental difference in evaluating C++ and Swift in a certain scenario, we will have to write different code for each of them. Like for example (from my limited understanding), when adding `Int8` and `Int32` in Swift we're supposed to return an error and not attempt any type promotions. On the other hand, we're making our own language, which can behave any way we want, so we can just add Swift numbers with C logic and get some result, which is potentially more useful than an error. https://github.com/llvm/llvm-project/pull/147064 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
