Where Builtin gets recognised in the compiler, during AST, Sema or during/after SIL stage?

You'll have to forgive me if this is a bit of a dumb question. I'm trying to debug issues with Builtin functions not being recognised, or extending the functions available via Builtin, or at least just understanding how it works.

I've grepped through the source for truncOrBitCast or the associated macros BUILTIN_CAST_OR_BITCAST_OPERATION, BUILTIN_CAST_OPERATION, BUILTIN.

Apart from in the .def file (Builtins.def), almost all of the references to the above seem to be during the SIL stages, including loads of optimisations. But if you use a builtin that's not recognised, it's (correctly) rejected with error during AST/Sema.

I guess I'm asking how does AST/Sema know about the builtins, where is the code?

OK, I think I'm going to end up answering my own question, at least partially. ;)

This code in lib/AST/Builtins.cpp looks like the code that parses Swift access to Builtin members:

ValueDecl *swift::getBuiltinValueDecl(ASTContext &Context, Identifier Id) {
  SmallVector<Type, 4> Types;
  StringRef OperationName = getBuiltinBaseName(Context, Id.str(), Types);
...

This is called from BuiltinUnit::LookupCache::lookupValue, called from BuiltinUnit::lookupValue, which is called from ModuleDecl::lookupValue.

There seems to be a list of FileUnits within a module, all of which is somehow primed with meta information for the Builtin module, rather than it being read from a .swiftmodule file or suchlike, for a traditional module.

In the case I'm looking at, getBuiltinValueDecl then calls through to getCastOperation, which returns a nullptr, that shows up as the identifier not parsing.

If anyone wants to correct or add to this, I'm all ears. :slight_smile:
Carl

Terms of Service

Privacy Policy

Cookie Policy