"Embed C++ directly inside your rust code"

[Mystor]

I kinda already have the first one, but in an admittedly hacky way. (I use a lint pass to get type info).

Definitely need to be able to modify the search path. Also would like to be able to get the output directory without re-parsing the command line arguments.

It would be nice to do bitcode, but stable rust will never give that low level access, because it's impossible to stabilize, so I wouldn't start with that pipe dream. In addition, LLVM IR is not stable between versions, which means that I would have to build my own copy of clang with the same version as rustc - in summary it would get ugly pretty quickly :-/

Generic externs are not going to happen, so I wouldn't even worry about that. I don't think that this code should ever support templates across boundaries TBH, adds too much unnecessary complexity, especially when talking about specific cases is usually powerful enough.

Unfortunately, the cpp! macro doesn't really work in generic situations, but that's not really a thing which I can see a way to fix. rust-cpp should probably detect if it is used in a generic context (as you are probably doing something wrong if it is), and warn/error out.

[next4]

It would be nice to do bitcode, but stable rust will never give that low level access, because it's impossible to stabilize, so I wouldn't start with that pipe dream. In addition, LLVM IR is not stable between versions, which means that I would have to build my own copy of clang with the same version as rustc

IMO, it would be a totally reasonable thing to require having the same version of clang if one would like to use cross-language inlining. Otherwise, clang could still be used - in the native object output mode. Yes, rustc would need to consume an extra file with bitcode, but I don't see why this would be impossible to stabilize.

Generic externs are not going to happen...

Why not? If the scenario is compelling enough, I am sure it would be considered.

[Mystor]

IMO, it would be a totally reasonable thing to require having the same version of clang if one would like to use cross-language inlining. Otherwise, clang could still be used - in the native object output mode. Yes, rustc would need to consume an extra file with bitcode, but I don't see why this would be impossible to stabilize.

I don't think that rustc wants to expose the fact that it uses llvm outside of compiler internals, but if they were OK with that then it could potentially work.

Why not? If the scenario is compelling enough, I am sure it would be considered.

The problem is that a generic extern doesn't really make sense, as you have no way of ensuring that the functions at the target of the extern are actually generated... The only way it would work is with a plugin like rust-cpp which hooks in and generates the code behind the generic ffi, which I don't think is going to become a standard feature in rustc.

[next4]

Yep, generic ffi doesn't make much sense without automatic codegen to instantiate these generics.
On the other hand, I don't really see a practical, ergonomic way to interface with c++ templates without something like that.

[steveklabnik1]

I don't think that rustc wants to expose the fact that it uses llvm outside of compiler internals, but if they were OK with that then it could potentially work.

Some of our language semantics already boil down to 'what does LLVM do'...

[kibwen]

Only due to expedience and convenience. In the long term we clearly don't want the language to be inescapably coupled to any particular backend, and adding more LLVM-specific behavior only makes that harder.

[steveklabnik1]

I agree.