Move MatchingEngine out of _MatchingEngine 😐
#143
Conversation
|
@rxwei Do you see any impact of this on the compiler integration side? |
|
Is it just moving from _ME to _SP? It should be fine as far as compiler integration is concerned. |
| // | ||
| //===----------------------------------------------------------------------===// | ||
|
|
||
| public // For prototypes |
There was a problem hiding this comment.
Whatever's public in _StringProcessing is public to the user. Why do we want to expose Program or MEProgram?
There was a problem hiding this comment.
It's because we're restricted to only 2 modules here. The engine should be its own module, internal to everything else, so that it can have API that's usable by prototypes and _StringProcessing. But since we have to slurp everything up into _StringProcessing, then this needs to service the prototypes too.
We can drop the prototypes support at some point, at which point this would be dropped. We have loads of public entities that we know we aren't going to ship as public already, so there will be an audit / purge. I can denote it with a FIXME comment or something to make it easier to find in the future.
There was a problem hiding this comment.
Would something like @_spi(PrototypeSupport) work?
milseman
force-pushed
the
head_scratching
branch
2 times, most recently
from
c2ace36 to
a2c3f68
Compare
|
@swift-ci please test linux platform |
milseman
force-pushed
the
head_scratching
branch
from
a2c3f68 to
9dd7871
Compare
|
@swift-ci please test linux platform |
Currently based on top of #142