Ensure symbol is associated with defined section

[marip8]

I ran into a use-case where I have two plugin libraries with different section names that use the same symbol name(s) to denote plugins. The plugin loader currently loops over the identified plugin libraries (which are ordered arbitrarily) and only checks if the symbol exists in the library before returning the first plugin it finds, regardless of whether that symbol is belongs to the section associated with the plugin typedef. In my case, it found the incorrect library first and caused a segfault because it didn't load the correct plugin object.

The fix provided in this PR adds two functions for checking the validity of a symbol in a library (hasSymbol). When the plugin type has a section, this method checks that the requested symbol is in the list of symbols associated with the section. Otherwise, it just checks if the library contains that symbol (i.e., the current behavior).

Note: the added method needs to be added to the class itself because it needs access to getSection which is generally a private method that is accessible to the PluginLoader class (via the friend class declaration in the plugin type) but is not accessible to other functions

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.39%. Comparing base (bb12780) to head (a5aeebc).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #33      +/-   ##
==========================================
+ Coverage   98.35%   98.39%   +0.04%     
==========================================
  Files           2        2              
  Lines         182      187       +5     
==========================================
+ Hits          179      184       +5     
  Misses          3        3              

Files with missing lines	Coverage Δ
include/boost_plugin_loader/plugin_loader.hpp	99.09% <100.00%> (+0.04%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Levi-Armstrong]

Its probably a good idea to add a unit test which confirms this works as expected and to ensure that it does not get broken in the future.

[Levi-Armstrong]

Does line 50 also need to be updated to leverage this?

[marip8]

If we make the call to hasSymbol before calling createSharedInstance, then no. I think we have that covered as far as this PR goes. As it stands now, trying to add hasSymbol to createSharedInstance is not possible because hasSymbol tries to call PluginT::getSection which is private and inaccessible to everything except the PluginLoader class. So we would have to make createSharedInstance a member of PluginLoader , which I didn't think was worth the extra change. Let me know if you would rather do that

[Levi-Armstrong]

We may just update the documentation to this function that it assumes that the symbol is a associated with the library and section.