Inconsistent indenting displaying for XML doc comments between base member and derived (impl'ed) member

[KyouyamaKazusa0805]

Version Used:

VS 17.6p1

Steps to Reproduce:

Define an interface member and append doc comments:

interface I
{
    /// <summary>
    /// A property.
    /// </summary>
    /// <remarks>
    /// <para>
    /// You can use this property like:
    /// <code><![CDATA[
    /// var result = Property;
    /// ]]></code>
    /// </para>
    /// </remarks>
    int Property { get; }
}

And then define a class that implements this property, and use <inheritdoc/> to inherit its doc comments:

class C : I
{
    /// <inheritdoc/>
    public int Property => 42;
}

Expected Behavior:

Both doc comments displayed in tooltip should be totally same.

Actual Behavior:

In derived (implemented) type, an unexpected indent will be inserted into the doc comments displayed in tooltip.

Screenshot:

Interface type:

Implemented type:

[mavasani]

@sharwell

[ghost]

@mavasani Hey, can I take this issue?

[sharwell]

@sdelarosbil Sure 👍

[ghost]

@sharwell Just giving a quick update on this: I believe I have found the cause of the issue and will be submitting a pr shortly. The fix seems straight forward, but the concern I have is what lead me to uncover this sounds like a different issue manifesting itseflf.

The issue boils down to an XDocument.Parse call not having a LoadOptions.PreserveWhitespace during the inheritdoc rewrite. This means that the following (which is enough to reproduce still):

/// <summary>
/// <code>
/// var test;
/// </code></summary>

Actually gets rewritten to this when an inheritdoc element is present:

/// <summary><code>
/// var test;
/// </code></summary>

This is due to not preserving the whitespaces of summary's child nodes. Semantically, these 2 should be equivalent, but this is what causes the indenting change which suggests there's a different problem: why would the newline's absence change the indentation?

Even if I give this the benefit of the doubt and assume it's done on purpose: it behaves in the opposite manner that I expect. It turns out the first snipped produces no trailing nor leading whitespaces while the second snipped produces \n var test;\n . The leading LF gets trimmed due to the code element's parsing logic, but the trailing LF and other spaces are still kept. If anything, I would have expected the first snippet to put an LF if any were supposed to be there, but it's actually the second one.

I don't think this finding changes the original fix as loosing the whitespaces when loading inheritdoc could lead to other problems and the whole pipeline seem to preserve them as much as possible anyway. What I am concerned about is if there should be another issue opened about this odd indentation behavior in the first place.