Bring over Erlang frontend from Lumen

[bitwalker]

This is the entirety of the Erlang frontend from Lumen, unfortunately I couldn't find a way to bring over the history, but we still have it in Lumen if needed for reference:

• Provides a diagnostics library for debug info and source spans
• Provides an Erlang frontend/parser built on LALRPOP
  • Supports all valid Erlang syntax
  • Supports all standard attributes (e.g. compiler directives, typespecs/callbacks, etc.)
  • Supports preprocessor directives/macro expansion

NOTE: This does not support parse transforms (yet). That is a difficult topic, since it requires evaluation of Erlang source code. While the preprocessor supports some degree of partial evaluation, it is limited to the things supported in preprocessor directives, whereas parse transforms require support for significantly more functionality, possibly the full language.

I chose the names diagnostics and frontend, but in my opinion we should reorganize this project's crates a bit, and provide some namespaced names instead. This will make it easier to publish individual crates, as well as provide some guidance on naming. I'll open a separate issue with my thoughts on that, just know that for now these are the names I've chosen, though I think they are not the names we ultimately want.

[bitwalker]

I added the Apache 2.0 as well, since that is what this code is covered under, I would recommend making it the project-wide license as well, but if you have a preference, I'm happy to discuss it, the only restriction is that the license remain compatible with Apache 2.0 if you choose a different one.

[hansihe]

As for the naming, some of the unpushed changes I have change that around a bit, most notably splitting the compiler crate into two more aptly named hir and core_frontend crates. I definitely agree that we should redo the entire naming scheme here.

[hansihe]

I fully agree with the Apache license, I just hadn't gotten around to adding a icense yet..

[bitwalker]

I'll leave merging this up to you, to avoid conflicts with your refactor work.

[lpil]

Would you like me to have a go at bringing over the history?

[bitwalker]

@lpil Lumen isn't yet open sourced (other than this part of it anyway), though it will be before long. If you have a suggestion on how to go about merging just the history for a particular set of files in a repo though, I'd be glad to give it a shot. As far as I'm aware, the only way to do this typically (other than in cases where subtree is used) is to add a remote to the other repo, ignoring the unrelated histories, do a merge of its master branch into the master of this repo (or a branch, same thing), and then perform whatever refactoring is needed. But this involves bringing in the entire history of the other repo, which we don't want.

Ultimately I'm not sure it's particularly worth the effort, if there was a lot of history, that'd be one thing, but there isn't a ton for this part and most of that history is from its work-in-progress phase anyway, so its not useful for doing bisects or any of the usual things you'd want the history for.

[lpil]

Ah right, that's more complex than I thought. If the changes your after live in one directory I believe you could extract them into a new repo, then merge that new repo into this one as you've suggested. Possibly not worth the work though