Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
support config extensions #138934
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
support config extensions #138934
Changes from all commits
1c1febc
89e3bef
4e80659
78cb453
3f70f19
8e6f50b
7dfb457
6d52b51
8270478
ac7d1be
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should put an assert here that
replace
isIgnoreDuplicates
? Because if it isn't, the priority logic of this function becomes wrong again.Also please add a comment that explains why we use this ordering; we need to first merge our own data when combined with IgnoreDuplicates, and only then apply the includes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But isn’t that relevant to the caller? I think that coverage is better handled by a unit test instead. There might not be any extra config in include in which case this function ends up working the same as it does on the current upstream master.
Sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function has an invariant that it keeps a certain preference order for profiles/includes/other parameters. This invariant only holds when
IgnoreDuplicates
is passed; if someone passes something else, the function breaks. So in that case we should add an assert.Arguably, the
merge
function shouldn't be used for includes and profiles, precisely because it only works with a single replace mode. The fact that you had to pass the original config path to the function kind of hints that the function is being abused and it is quite hacky :) But I don't want to block this PR further, let's keep it like it is, and just add an assert to make sure that it won't silently change behavior in the future without us knowing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really prefer to resolve this FIXME and handle that case properly with a test coverage rather than adding that assertion into the implementation details. I will try to allocate some time to do it by the end of today or early tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A test would be nice, but that doesn't change the fact that if the function is called with a different argument, it will silently break its behavior. Assertions are useful exactly for these kinds of situations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was confused by this at first, but then I realized that
profile
merging is "lazy"; in includes, only theprofile
value is overwritten, but the final profile is only applied in the root config, not for the intermediate included configs. I guess that in most cases this won't be an issue, but it deserves at least a comment.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get it, could you clarify how does this cause an override? It should only use the root profile and ignore the rest if there are any.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I thought would happen is that profile replacement is "eager", in other words if you have something like this:
Then
b.toml
will be "filled" with data frombaz
, thena.toml
will be "filled" with data fromfoo
etc. But what happens is that only theprofile
key is overwritten, and the profile itself is only expanded in the root. That's probably fine though, I couldn't think of a situation where that is not what we want.One weird thing that I just realized related to this is that the
profile
key now has higher precedence in the parent than theprofile
key in the child. So in the example above, thebar
profile will be actually applied, even though I would expect thatbaz
will be applied.