| Age | Commit message (Collapse) | Author | Lines |
|---|
|
LLVM 8 was released on March 20, 2019, over a year ago.
|
|
Finding the `SourceFile` associated with a `FileName` called `get_source_file` on
the `SourceMap`, which does a linear search through all files in the `SourceMap`.
This resolves the issue by passing the SourceFile in from the caller (which already
had it available).
|
|
* Adds either an MD5 or SHA1 hash to the debug info.
* Adds new unstable option `-Z src-hash-algorithm` to control the hashing algorithm.
|
|
|
|
(clippy::single_match)
Makes code more compact and reduces nestig.
|
|
|
|
|
|
rustc: keep upvars tupled in {Closure,Generator}Substs.
Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`.
Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods.
To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are:
* before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]`
* after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]`
You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types.
r? @nikomatsakis cc @Zoxc
|
|
-Cdebuginfo=1.
|
|
|
|
|
|
|
|
Emit 1-based column numbers in debuginfo
* Use byte offsets instead of char position offsets. Resolves #67360.
* Use 1-based offsets instead of 0-based ones. Resolves #65437.
* Consistently omit column information for msvc targets, matching clang behaviour (previously columns have been omitted from `DILocation`, but not from `DILexicalBlock`).
|
|
|
|
Additionally whenever possible match C API provided by the LLVM.
|
|
Change DIBuilderCreateEnumerator signature to match LLVM 9
* Change DIBuilderCreateEnumerator signature to match LLVM 9 C API.
* Use provided is unsigned flag when emitting enumerators.
|
|
fix various typos
|
|
|
|
|
|
|
|
No functional changes intended.
|
|
|
|
simplify boolean expressions
|
|
|
|
|
|
|
|
|
|
Nix `rustc_hir` reexports in rustc::hir
r? @Zoxc cc @Mark-Simulacrum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.
Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).
The end results of this change are:
* Rustbuild's build process for the compiler as all the "oh don't forget
the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
parallelism in the main rustc build step rather than splitting
`librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
multiple codegen backends is still supported, and dynamic loading of a
codegen backend is still supported.
|
|
VarDebugInfo.
|
|
|
|
|
|
|
|
We also sever syntax's dependency on rustc_target as a result.
This should slightly improve pipe-lining.
Moreover, some cleanup is done in related code.
|
|
Remove `InternedString`
This PR removes `InternedString` by converting all occurrences to `Symbol`. There are a handful of places that need to use the symbol chars instead of the symbol index, e.g. for stable sorting; local conversions `LocalInternedString` is used in those places.
r? @eddyb
|
|
This avoids the needs for various conversions, and makes the code
slightly faster, because `Symbol` comparisons and hashing is faster.
|
|
|
|
Replace some instances of `as *[const | mut] _` with `.cast()`
While in `codegen_llvm`, noticed some places for the recent `pointer::cast` method.
|
|
|
|
|
|
|
|
|
|
|
