[llvm-bugs] [Bug 24401] New: Spacing issue with "UseTab=Always" option

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Aug 8 09:36:34 PDT 2015


https://llvm.org/bugs/show_bug.cgi?id=24401

            Bug ID: 24401
           Summary: Spacing issue with "UseTab=Always" option
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Formatter
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cbeck at princeton.edu
                CC: djasper at google.com, klimek at google.com,
                    llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 14713
  --> https://llvm.org/bugs/attachment.cgi?id=14713&action=edit
Patch which adds a unit test demonstrating the bug, @git revision
9d19c31c0b500c54d9276d4d8d0748a0820abe68

When using "UseTab=Always" together with "AlignTrailingComments", I get
misaligned trailing comments. The issue is fixed by using
"UseTab=ForIndentation".

I took an example from my project and coded it up as a clang unit test, patch
attached.

To make the issue concrete, here's what it looks like with
"UseTab=ForIndentation":

if (it != bytecode_cache_.end()) {
    lua_pushstring(L, bytecode_cache_key);     // key
    lua_rawget(L, LUA_REGISTRYINDEX);       // cache_table
    lua_rawgeti(L, -1, it->second);           // cache_table bytecode
    lua_remove(L, -2);               // bytecode
    lua_insert(L, -1 - nargs);           // bytecode [args x nargs]
    return protected_call(nargs);           //
} else if (load_string(script)) {           // bytecode
    lua_pushstring(L, bytecode_cache_key);     // bytecode key
    lua_rawget(L, LUA_REGISTRYINDEX);       // bytecode cache_table
    lua_pushvalue(L, -2);               // bytecode cache_table bytecode
    bytecode_cache_[script] = luaL_ref(L, -2); // bytecode cache_table
    lua_pop(L, 1);                   // bytecode
    lua_insert(L, -1 - nargs);           // bytecode [args x nargs]
    return protected_call(nargs);           //
} else {
    return false;
}

Here's what it looks like with "UseTab=Always"

if (it != bytecode_cache_.end()) {
    lua_pushstring(L, bytecode_cache_key);     // key
    lua_rawget(L, LUA_REGISTRYINDEX);      // cache_table
    lua_rawgeti(L, -1, it->second);           // cache_table bytecode
    lua_remove(L, -2);               // bytecode
    lua_insert(L, -1 - nargs);           // bytecode [args x nargs]
    return protected_call(nargs);           //
} else if (load_string(script)) {           // bytecode
    lua_pushstring(L, bytecode_cache_key);     // bytecode key
    lua_rawget(L, LUA_REGISTRYINDEX);      // bytecode cache_table
    lua_pushvalue(L, -2);               // bytecode cache_table bytecode
    bytecode_cache_[script] = luaL_ref(L, -2); // bytecode cache_table
    lua_pop(L, 1);                   // bytecode
    lua_insert(L, -1 - nargs);           // bytecode [args x nargs]
    return protected_call(nargs);           //
} else {
    return false;
}

The patch is a clang unit test (valid against master branch git commit
9d19c31c0b500c54d9276d4d8d0748a0820abe68) which tests that this is indeed the
current (incorrect) behavior, using style with minimal changes from LLVM style
which generates the behavior.

I tried to figure out how to fix it, I think that potentially the issue might
be a logic error here?

https://github.com/llvm-mirror/clang/blob/45aa4ad6e537866b40fe9574fa992bf3d6593e39/lib/Format/WhitespaceManager.cpp#L422

The code comment says "Indent with tabs only when there's at least one full
tab", and checks if the desired number of spaces is at least "FirstTabWidth"
(the width the first tab would have) + the width of a full tab. If so it emits
one tab character and subtracts that many spaces. Then we assume we are tab
aligned, and emit Spaces / TabWidth tabs, and Spaces % TabWidth spaces.

However, in the case that the tested condition fails, presumably we aren't
supposed to emit any tabs and should only emit spaces, but we will do so
anyways, at line 427.

I experimented by changing the code, to negate the condition and cause it to
simply emit "Spaces" many spaces and return when the condition has failed,
otherwise it follows the same code path as before. However, this breaks several
other unit tests. So I thought I should just submit what I've done as an issue
to the bugtracker instead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150808/a02ac2f4/attachment.html>


More information about the llvm-bugs mailing list