Remove the term "whitelist" #3457
Conversation
|
LGTM |
|
MoreInfo 6/12 by ML Shiproom. @tmeschter, please talk to @amcasey regarding the references changes. |
|
It looks like it just pretty-printed the references. I'd be tempted to revert the change to make it easier to find the automatically-generated Private elements later. |
|
Right, VS just reformatted the project file when the file names were updated. I'll undo that part. |
We have a couple of places where we check that the set of analyzer assemblies is internally consistent and complete--that is, for any given assembly in that set, all of its dependencies are satisfied by other assemblies in the set. We expect certain dependencies to be satisfied by the host, and so want to ignore them if they are not found in the the analyzer assembly set. We referred to these host-provided dependencies as a white list, but Policheck does not like that term. Instead, we now refer to these as the "ignorable assembly list".
|
@amcasey @MattGertz @ManishJayaswal I've simply updated the pull request to avoid changes to the This is ready to go back to ship room. |
|
Approved 6/15 by ML Shiproom. Approved pending a successful Jenkins run. |
|
Blah. I opened this pull request against master instead of stabilization. I'll close this pull request and open a new one. |
|
This was handled by #3507. |
Bug: Fixes DevDiv Bug 1185799
Customer Scenario
No customer scenario, per se.
There are a number of places where we use the term "whitelist", and one of them (a code comment) was flagged by Policheck. Given that our code is open I've gone ahead and simply fixed them all.
Fix
Several internal types were updated with new names, as well as various fields, locals, and a comment.
Testing
After the fix, the code still passes all of our unit and integration tests.
@ManishJayaswal This is ready to go to ship room.
@srivatsn @mavasani @shyamnamboodiripad @heejaechang @jmarolf @AlekseyTs Could you take a look as well?