[SERVER-74162] Move third_party include from stemmer.h to stemmer.cpp Created: 17/Feb/23  Updated: 29/Oct/23  Resolved: 18/Feb/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.0.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Daniel Moody Assignee: Billy Donahue
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Backwards Compatibility: Fully Compatible
Sprint: Service Arch 2023-02-20
Participants:

 Description   

This would allow us to remove the stemmer include path from most of the compilation commands.



 Comments   
Comment by Githook User [ 18/Feb/23 ]

Author:

{'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}

Message: SERVER-74162 Stemmer pImpl to hide third_party dep
Branch: master
https://github.com/mongodb/mongo/commit/bdb4dff3cbb57e206f2a5de38863b11e8646a197

Comment by Billy Donahue [ 17/Feb/23 ]

I can knock this out in a few minutes.

Comment by Billy Donahue [ 17/Feb/23 ]

Generally a header should only be forward-declaring types that the header is packaged with and defines the definition of. This important rule avoids risk of ODR violations and many other subtle problems.

The goal is to remove the third_party/.../libstemmer.h include from mongo/db/fts/stemmer.h.
The ticket desc is specifying a way to do that, but I think isn't quite the best way to do it.

I think a full pimpl pattern there would be even better than a fwd decl of a third_party class sb_stemmer.

Either way we get the include of the third_party/libstemmer_c/include/libstemmer.h out of our stemmer.h and confine it to the .cpp file. But we'd only be forward declaring a nested Impl class that's defined by the .cpp, and not a third_party type.

Comment by Alex Neben [ 17/Feb/23 ]

I don't know if service arch is the right place for this request but I think Jason/Blake will have a better idea of who owns stemmer.

Generated at Thu Feb 08 06:26:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.