Steps to Reproduce: In llvm/tools/clang/test/FixIt run $ clang -fsyntax-only fixit-include.c Actual Results: fixit-include.c:7:10: error: 'fixit-include.h' file not found with <angled> include; use "quotes" instead #include <fixit-include.h> // expected-error {{'fixit-include.h' file not found with <angled> include; use "quotes" instead}} ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "fixit-include.h" 1 error generated. Expected Results: fixit-include.c:7:10: error: 'fixit-include.h' file not found with <angled> include; use "quotes" instead #include <fixit-include.h> // expected-error {{'fixit-include.h' file not found with <angled> include; use "quotes" instead}} ^~~~~~~~~~~~~~~~~ "fixit-include.h" 1 error generated. I.e. fixit range shouldn't go beyond right angled bracket. Build Date & Platform: Build 09/20/2012 (r164256) on Mac OS X 10.6.8.
This was caused by r163588.
Created attachment 9239 [details] Use in InclusionDirective separate location variable pointing before > Looks like this bug was introduced in r163588: in lib/Lex/PPDirectives.cpp by case tok::angle_string_literal: case tok::string_literal: Filename = getSpelling(FilenameTok, FilenameBuffer); End = FilenameTok.getLocation(); + // For an angled include, point the end location at the closing '>'. + if (FilenameTok.is(tok::angle_string_literal)) + End = End.getLocWithOffset(Filename.size()-1); CharEnd = End.getLocWithOffset(Filename.size()); break; Later CharEnd is used to compute fixit range, causing too long range. Also the same problem should be present for @__experimental_modules_import fixit, but I didn't try to reproduce it. I'd like to note that mentioned change also causes clang::SourceManager::getIncludeLoc(FileID FID) const to return location pointing at '>'. But for include-what-you-use tool I need to get include name as typed and it was convenient when getIncludeLoc() returned location pointing at '<' or '"' (opening quotation mark). I've created a patch according to my getIncludeLoc() preferences which fixes this issue. Please find patch attached.
We're already in discussion about the right way to fix this: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120917/064551.html
Fixed in r164743.
Confirm that bug is fixed. Should I change the issue state to VERIFIED or CLOSED?