fix isPathShadowedInFlatMap type cast bug

[linuxsong]

The cast.ToStringMap() method calls ToStringMapE() for type conversion, but ToStringMapE() does not support conversion from map[string]string and map[string]FlagValue to map[string]interface{}, so when calling the isPathShadowedInFlatMap() method, ToStringMapE will always return a " unable to cast %#v of type %T to map[string]interface{}" error, so the isPathShadowedInFlatMap() method does nothing.

So in the isPathShadowedInFlatMap method, should to call castMapStringToMapInterface and castMapFlagToMapInterface() respectively to convert map[string]string and map[string]FlagValue into map[string]interface{}.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

👋 Thanks for contributing to Viper! You are awesome! 🎉

A maintainer will take a look at your pull request shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

[sagikazarmark]

@linuxsong thank you for your contribution!

Could you provide a test that fails without this change, so we can make sure we don't reintroduce this bug later?

Thanks!

[linuxsong]

@linuxsong thank you for your contribution!

Could you provide a test that fails without this change, so we can make sure we don't reintroduce this bug later?

Thanks!

I added a unit test. It will fails without this change. Please help to review.

[sagikazarmark]

@linuxsong thank you for providing a test.

Is this issue reproducible using the public API of Viper?

For example, can you reproduce it using flags manually passed in?

If so it would be better to write a blackbox test (as well) that doesn't rely on internals, so if any refactoring happens we can safely make changes around the internal code without breaking existing features.

Here is what I would do (although I'm not sure how to reproduce the problem):

Write a test that:

• configures a flag value
• reads in config or sets a default value
• asserts that shadowing happens (or not) by reading from Viper

[linuxsong]

@linuxsong thank you for providing a test.

Is this issue reproducible using the public API of Viper?

For example, can you reproduce it using flags manually passed in?

If so it would be better to write a blackbox test (as well) that doesn't rely on internals, so if any refactoring happens we can safely make changes around the internal code without breaking existing features.

Here is what I would do (although I'm not sure how to reproduce the problem):

Write a test that:

• configures a flag value
• reads in config or sets a default value
• asserts that shadowing happens (or not) by reading from Viper

@sagikazarmark thank you for your review.
I use public API of Viper write a new unit test reproduce the issue. Without this fix the test case would fail.
Please help to review again.

[sagikazarmark]

Thanks!