mentions macros that must necessarily be whitebox

Author: xeno-by

overviews/macros/extractors.md

@@ -86,3 +86,5 @@ Follow our test cases at [run/t5903a](https://github.com/scala/scala/tree/00624a
 [run/t5903c](https://github.com/scala/scala/tree/00624a39ed84c3fd245dd9df7454d4cec4399e13/test/files/run/t5903c),
 [run/t5903d](https://github.com/scala/scala/tree/00624a39ed84c3fd245dd9df7454d4cec4399e13/test/files/run/t5903d) to see implementations
 of this and other use cases for extractor macros.
+
+Please note that extractor macros must be [whitebox](/overviews/macros/blackbox-whitebox.html), otherwise they will not work.

overviews/macros/implicits.md

@@ -140,12 +140,11 @@ problem is extremely simple and elegant.
 In 2.10 we don't allow macro applications to expand until all their type arguments are inferred. However we don't have to do that.
 The typechecker can infer as much as it possibly can (e.g. in the running example `C` will be inferred to `Foo` and
 `L` will remain uninferred) and then stop. After that we expand the macro and then proceed with type inference using the type of the
-expansion to help the typechecker with previously undetermined type arguments.
+expansion to help the typechecker with previously undetermined type arguments. This is how it's implemented in Scala 2.11.0.
 
-An illustration of this technique in action can be found in our [files/run/t5923c](https://github.com/scalamacros/kepler/tree/7b890f71ecd0d28c1a1b81b7abfe8e0c11bfeb71/test/files/run/t5923c) tests.
+An illustration of this technique in action can be found in our [files/run/t5923c](https://github.com/scala/scala/tree/7b890f71ecd0d28c1a1b81b7abfe8e0c11bfeb71/test/files/run/t5923c) tests.
 Note how simple everything is. The `materializeIso` implicit macro just takes its first type argument and uses it to produce an expansion.
 We don't need to make sense of the second type argument (which isn't inferred yet), we don't need to interact with type inference -
 everything happens automatically.
 
-Please note that there is [a funny caveat](https://github.com/scalamacros/kepler/blob/7b890f71ecd0d28c1a1b81b7abfe8e0c11bfeb71/test/files/run/t5923a/Macros_1.scala)
-with Nothings that we plan to address later.
+Please note that there is [a funny caveat](https://github.com/scala/scala/blob/7b890f71ecd0d28c1a1b81b7abfe8e0c11bfeb71/test/files/run/t5923a/Macros_1.scala) with Nothings that we plan to address later. Also note that fundep materializers must be [whitebox](/overviews/macros/blackbox-whitebox.html), otherwise they will not work.

overviews/macros/typeproviders.md

@@ -84,6 +84,8 @@ it has performance problems caused by the fact that Scala emits reflective calls
 of structural types. There are several strategies of dealing with that, but this margin is too narrow to contain them
 so I refer you to an amazing blog series by Travis Brown for details: [post 1](http://meta.plasm.us/posts/2013/06/19/macro-supported-dsls-for-schema-bindings/), [post 2](http://meta.plasm.us/posts/2013/07/11/fake-type-providers-part-2/), [post 3](http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/).
 
+Please note that fake type providers must be [whitebox](/overviews/macros/blackbox-whitebox.html), otherwise they will not work.
+
 ### Real type providers
 
 With the help of [macro paradise](/overviews/macros/paradise.html) and its [macro annotations](/overviews/macros/annotations.html), it becomes