<p>Similar to <a href="https://stackoverflow.com/questions/288794/does-c-optimize-the-concatenation-of-string-literals">this</a> question, but for VB.NET since I learned this is a language thing.</p>

<p>For instance, would the compiler know to translate</p>

<blockquote>
  <p>Dim s As String = "test " + "this " +
  "function"</p>
</blockquote>

<p>to</p>

<pre><code>Dim s As String = "test this function"
</code></pre>

<p>and thus avoid the performance hit with the string concatenation?</p>

While I'm looking it up,
here's the download page for the spec
.
Section 11.2 looks like it
would
be the right bit - it's basically the equivalent of 7.18 in the C# 3.0 spec - but it doesn't contain the same guarantee. I suspect the compiler still does it, but I can't see any guarantee. I'll have another look though.
Section 11.2 does state that "A constant expression is an expression
whose value can be fully evaluated at compile time
" (my emphasis) but I can't see that it actually guarantees that it
will
fully evaluate it at compile time. Frankly it would be odd to make a category of expression based on this condition but not actually use it.
A quick test shows that the current VB compiler does indeed do the concatenation at compile time, but there really
should
be a guarantee in the spec if that's the intention.
Section 7.3 get a bit closer:
When the operands of an expression are
  all primitive type constants, it is
  possible for the compiler to evaluate
  the expression at compile time. Such
  an expression is known as a constant
  expression.
Now String isn't a primitive type in terms of the CLR (
Type.IsPrimitive
would return false) but it
is
in terms of the VB spec.
It's still not saying that it
will
evaluate it though...