- 29 7月, 2016 31 次提交
-
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
This was changed back in https://github.com/rust-lang/llvm/commit/aacf2fbf
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
Previously, we had a PositionIndependentExecutable, now we simply choose the highest level. This should be equivalent.
🍰 -
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
This was deleted here[1] which appears to be replaced by this[2] which is a new setPIELevel function on the LLVM module itself. [1]: http://reviews.llvm.org/D19753 [2]: http://reviews.llvm.org/D19671
-
由 Jan-Erik Rediger 提交于
The new NewArchiveMember is simpler and requires less context, according to upstream. This was changed in http://reviews.llvm.org/D21721
-
由 Jan-Erik Rediger 提交于
This makes sure to still use the old way for older LLVM versions.
-
由 Jan-Erik Rediger 提交于
LLVM pass manager infrastructure is currently getting rewritten to be more flexible, but the rewrite isn't complete yet.
-
由 Jan-Erik Rediger 提交于
Since LLVM reversed the order of the debug info graphs, we need to have a compile unit that exists *before* any functions (`DISubprogram`s) are created. This allows the LLVM debug info builder to automatically link the functions to the compile unit.
-
由 Jan-Erik Rediger 提交于
-
由 Jan-Erik Rediger 提交于
-
由 bors 提交于
switch mipsel-musl to soft float Closes #34922. r? @alexcrichton
-
由 bors 提交于
Enable reuse of `.o` files if nothing has changed This PR completes a first "spike" for incremental compilation by enabling us to reuse `.o` files when nothing has changed. When in incr. mode, we will save `.o` files into the temporary directory, then copy them back out again if they are still valid. The code is still a bit rough but it does seem to work. =) r? @michaelwoerister Fixes #34036 Fixes #34037 Fixes #34038
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
actually we shouldn't even hash nested items at all, but that is addressed in a followup PR
-
由 bors 提交于
Escape fewer Unicode codepoints in `Debug` impl of `str` Use the same procedure as Python to determine whether a character is printable, described in [PEP 3138]. In particular, this means that the following character classes are escaped: - Cc (Other, Control) - Cf (Other, Format) - Cs (Other, Surrogate), even though they can't appear in Rust strings - Co (Other, Private Use) - Cn (Other, Not Assigned) - Zl (Separator, Line) - Zp (Separator, Paragraph) - Zs (Separator, Space), except for the ASCII space `' '` `0x20` This allows for user-friendly inspection of strings that are not English (e.g. compare `"\u{e9}\u{e8}\u{ea}"` to `"éèê"`). Fixes #34318. CC #34422. [PEP 3138]: https://www.python.org/dev/peps/pep-3138/
-
由 Niko Matsakis 提交于
In the older version, a `.o` and ` .bc` file were separate work-products. This newer version keeps, for each codegen-unit, a set of files of different kinds. We assume that if any kinds are available then all the kinds we need are available, since the precise set of switches will depend on attributes and command-line switches. Should probably test this: the effect of changing attributes in particular might not be successfully tracked?
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
This checks the `previous_work_products` data from the dep-graph and tries to simply copy a `.o` file if possible. We also add new work-products into the dep-graph, and create edges to/from the dep-node for a work-product.
-
由 Niko Matsakis 提交于
Work products are deleted if any of their inputs are dirty.
-
由 Niko Matsakis 提交于
We used to use `Name`, but the session outlives the tokenizer, which means that attempts to read this field after trans has complete otherwise panic. All reads want an `InternedString` anyhow.
-
由 Niko Matsakis 提交于
A work product right now is just a `.o` file. In the future it probably includes other kinds of files, such as `.bc` files saving the unoptimized LLVM IR. However, because WorkProductIds must be independent of DefIds, so that they don't need translation, this system may not be suitable *as is* for storing fine-grained information (such as the MIR for individual defs), as it was originally intended. We will want to refactor some for that.
-
- 28 7月, 2016 9 次提交
-
-
由 bors 提交于
Rollup of 7 pull requests - Successful merges: #34951, #34963, #34969, #35013, #35037, #35040, #35058 - Failed merges:
-
由 Manish Goregaokar 提交于
Use &mut for `CombineFields` in inference relations Because dropping obligations on the floor makes a mess. r? @nikomatsakis
-
由 Manish Goregaokar 提交于
rustdoc: Fix tuple struct where clause rendering For tuple structs the where clause comes after the definition. Fixes #34928
-
由 Manish Goregaokar 提交于
move coerce-match{,-calls} into run-pass-valgrind Closes #21696.
-
由 Manish Goregaokar 提交于
Avoid processing `feature`s on unconfigured crates Fixes #34932, a regression caused by #34272. r? @nrc
-
由 Manish Goregaokar 提交于
resolve: Fix ICE and extra diagnostics happening when unresolved imports are used in patterns Closes https://github.com/rust-lang/rust/issues/34933 r? @jseyfried
-
由 Manish Goregaokar 提交于
Make vec::Drain and binary_heap::Drain covariant I removed all mutable pointers/references, and added covariance tests similar to the ones in #32635. It builds and passes the tests, but I noticed that there weren't any tests of Drain's behaviour (at least not in libcollectionstest), so I'm not sure if my changes accidently broke Drain's behaviour. Should I add some tests for that (and if so, what should the tests include)?
-
由 bors 提交于
Make vec::Drain and binary_heap::Drain covariant I removed all mutable pointers/references, and added covariance tests similar to the ones in #32635. It builds and passes the tests, but I noticed that there weren't any tests of Drain's behaviour (at least not in libcollectionstest), so I'm not sure if my changes accidently broke Drain's behaviour. Should I add some tests for that (and if so, what should the tests include)?
-
由 bors 提交于
macros: Improve `tt` matchers Fixes #5846, fixes #22819. r? @nrc
-