| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
driver taking lib/Driver.
llvm-svn: 65811
|
|
|
|
| |
llvm-svn: 63551
|
|
|
|
|
|
| |
contains no error reports.
llvm-svn: 62871
|
|
|
|
|
|
| |
plist file per translation unit that contains all of the diagnostics.
llvm-svn: 62647
|
|
|
|
|
|
| |
no longer such thing as a non-canonical FileID.
llvm-svn: 62499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"FileID" a concept that is now enforced by the compiler's type checker
instead of yet-another-random-unsigned floating around.
This is an important distinction from the "FileID" currently tracked by
SourceLocation. *That* FileID may refer to the start of a file or to a
chunk within it. The new FileID *only* refers to the file (and its
#include stack and eventually #line data), it cannot refer to a chunk.
FileID is a completely opaque datatype to all clients, only SourceManager
is allowed to poke and prod it.
llvm-svn: 62407
|
|
|
|
|
|
| |
*is* the location. This eliminates some weird X.getLocation().getLocation()'s.
llvm-svn: 62376
|
|
|
|
|
|
| |
"logical" location, refer to the "instantiation" location.
llvm-svn: 62316
|
|
|
|
|
|
|
|
| |
the Backend output should be done in binary mode.
- I'd appreciate it if someone who has a Windows build could verify
this.
llvm-svn: 59221
|
|
|
|
|
|
| |
Fix Plist output.
llvm-svn: 58652
|
|
llvm-svn: 58647
|