- 02 8月, 2016 1 次提交
-
-
由 Jeffrey Seyfried 提交于
-
- 01 8月, 2016 11 次提交
-
-
由 bors 提交于
LLVM upgrade As discussed in https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154/46 I'm trying to update the used LLVM checkout in Rust. I basically took @shepmaster's code and applied it on top (though I did the commits manually, the [original commits have better descriptions](https://github.com/rust-lang/rust/compare/master...avr-rust:avr-support). With these changes I was able to build rustc. `make check` throws one last error on `run-pass/issue-28950.rs`. Output: https://gist.github.com/badboy/bcdd3bbde260860b6159aa49070a9052 I took the metadata changes as is and they seem to work, though it now uses the module in another step. I'm not sure if this is the best and correct way. Things to do: * [x] ~~Make `run-pass/issue-28950.rs` pass~~ unrelated * [x] Find out how the `PositionIndependentExecutable` setting is now used * [x] Is the `llvm::legacy` still the right way to do these things? cc @brson @alexcrichton
-
由 bors 提交于
trans: Avoid weak linkage for closures when linking with MinGW. This PR proposes one possible solution to #34793, the problem that prevents https://github.com/servo/servo/pull/12393 from landing. It applies the same strategy, that we already use for monomorphizations, to closures, that is, instead of emitting symbols with `weak_odr` linkage in order to avoid symbol conflicts, we emit them with `internal` linkage, with the side effect that we have to copy code instead of just linking to it, if more than one codegen unit is involved. With this PR, the compiler will only apply this strategy for targets where we would actually run into a problem when using `weak_odr` linkage, in other words nothing will change for platforms except for MinGW. The solution implemented here has one restriction that could be lifted with some more effort, but it does not seem to be worth the trouble since it will go away once we use only MIR-trans: If someone compiles code 1. on MinGW, 2. with more than one codegen unit, 3. *not* using MIR-trans, 4. and runs into a closure inlined from another crate then the compiler will abort and suggest to compile either with just one codegen unit or `-Zorbit`. What's nice about this is that I lays a foundation for also doing the same for generics: using weak linkage where possible and thus enabling some more space optimizations that the linker can do. ~~This PR also contains a test case for compiling a program that contains more than 2^15 closures. It's a huge, generated file with almost 100K LOCs. I did not commit the script for generating the file but could do so. Alternatively, maybe someone wants to come up with a way of doing this with macros.~~ The test file is implemented via macros now (thanks @alexcrichton!) Opinions? Fixes #34793. cc @rust-lang/compiler
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Jan-Erik Rediger 提交于
@tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.
-
由 bors 提交于
Suppress unused type parameter error when type has error field Fix #35075.
-
由 bors 提交于
Add libarena from local rust to stage0 This was needed at least when local rust was 1.9.0 on darwin. Fixes #35149
-
由 Brendan Cully 提交于
This was needed at least when local rust was 1.9.0 on darwin. Fixes #35149
-
由 bors 提交于
typeck: use a TypeVisitor in ctp Use a TypeVisitor in ctp instead of `ty::walk` This fixes a few cases where a region could be projected out of a trait while not being constrained by the type parameters, violating rust-lang/rfcs#447 and breaking soundness. As such, this is a [breaking-change]. Fixes #35139 r? @EddyB
-
由 Ariel Ben-Yehuda 提交于
Fixes #35139
-
由 bors 提交于
Avoid writing a temporary closure kind We used to write a temporary closure kind into the inference table, but this could lead to obligations being incorrectled resolved before inference had completed. This result could then be cached, leading to further trouble. This patch avoids writing any closure kind until the computation is complete. Fixes #34349. r? @arielb1 -- what do you think?
-
- 31 7月, 2016 18 次提交
-
-
由 bors 提交于
diagnostically note source of overruling outer forbid When we emit E0453 (lint level attribute overruled by outer `forbid` lint level), it could be helpful to note where the `forbid` level was set, for the convenience of users who, e.g., believe that the correct fix is to weaken the `forbid` to `deny`. ![forbidden_on_whose_authority](https://cloud.githubusercontent.com/assets/1076988/15995312/2d847376-30ce-11e6-865e-b68cfebc0291.png)
-
由 bors 提交于
Suggest use of `--print target-list` when target is not found. If given target could not be found suggest using `--print target-list`. Previously, error has been reported as: $ rustc --target 86-unknown-linux-gnu error: Error loading target specification: Could not find specification for target "86-unknown-linux-gnu" After changes it looks as follows: $ rustc --target 86-unknown-linux-gnu error: Error loading target specification: Could not find specification for target "x86-unknown-linux-gnu". Use `--print target-list` for a list of supported targets
-
由 Tomasz Miąsko 提交于
If given target could not be found suggest using `--print target-list`. Previously, error has been reported as: $ rustc --target x86-unknown-linux-gnu error: Error loading target specification: Could not find specification for target "x86-unknown-linux-gnu" After changes it looks as follows: rustc --target x86-unknown-linux-gnu error: Error loading target specification: Could not find specification for target "x86-unknown-linux-gnu" help: Use `--print target-list` for a list of built-in targets
-
由 bors 提交于
Add ARM MUSL targets Rebase of #33189. I tested this by producing a std for `arm-unknown-linux-musleabi` then I cross compiled Hello world to said target. Checked that the produced binary was statically linked and verified that the binary worked under QEMU. This depends on rust-lang/libc#341. I'll have to update this PR after that libc PR is merged. I'm also working on generating ARM musl cross toolchain via crosstool-ng. Once I verified those work, I'll send a PR to rust-buildbot. r? @alexcrichton cc @timonvo
-
由 bors 提交于
Properly feature gate all unstable ABIs Fixes https://github.com/rust-lang/rust/issues/34900 [breaking-change] r? @pnkfelix --- Function-visiting machinery for AST/HIR is surprisingly error-prone, it's *very* easy to miss some cases or visit something twice while writing a visitor. This is the true problem behind https://github.com/rust-lang/rust/issues/34900. I'll try to restructure these visitors a bit and send one more PR later.
-
由 Zack M. Davis 提交于
When we emit E0453 (lint level attribute overruled by outer `forbid` lint level), it could be helpful to note where the `forbid` level was set, for the convenience of users who, e.g., believe that the correct fix is to weaken the `forbid` to `deny`.
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
it's the same as linux_musl_base
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Timon Van Overveldt 提交于
The targets are: - `arm-unknown-linux-musleabi` - `arm-unknown-linux-musleabihf` - `armv7-unknown-linux-musleabihf` These mirror the existing `gnueabi` targets. All of these targets produce fully static binaries, similar to the x86 MUSL targets. For now these targets can only be used with `--rustbuild` builds, as https://github.com/rust-lang/compiler-rt/pull/22 only made the necessary compiler-rt changes in the CMake configs, not the plain GNU Make configs. I've tested these targets GCC 5.3.0 compiled again musl-1.1.12 (downloaded from http://musl.codu.org/). An example `./configure` invocation is: ``` ./configure \ --enable-rustbuild --target=arm-unknown-linux-musleabi \ --musl-root="$MUSL_ROOT" ``` where `MUSL_ROOT` points to the `arm-linux-musleabi` prefix. Usually that path will be of the form `/foobar/arm-linux-musleabi/arm-linux-musleabi`. Usually the cross-compile toolchain will live under `/foobar/arm-linux-musleabi/bin`. That path should either by added to your `PATH` variable, or you should add a section to your `config.toml` as follows: ``` [target.arm-unknown-linux-musleabi] cc = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-gcc" cxx = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-g++" ``` As a prerequisite you'll also have to put a cross-compiled static `libunwind.a` library in `$MUSL_ROOT/lib`. This is similar to [how the x86_64 MUSL targets are built] (https://doc.rust-lang.org/book/advanced-linking.html).
-
由 Timon Van Overveldt 提交于
This is to pull in changes to support ARM MUSL targets. This change also commits a couple of other cargo-generated changes to other dependencies in the various Cargo.toml files.
-
由 bors 提交于
Only export #[no_mangle] extern symbols during LTO Fixes #34985
-
由 bors 提交于
On Windows, ensure PATH does not contain invalid character `"` Fixes #34959. r? @alexcrichton
-
- 30 7月, 2016 10 次提交
-
-
由 Seo Sanghyeon 提交于
-
由 bors 提交于
Rollup of 8 pull requests - Successful merges: #35049, #35058, #35063, #35080, #35090, #35094, #35104, #35106 - Failed merges:
-
由 Manish Goregaokar 提交于
syntax_ext: format: fix ICE with bad named arguments Fixes #35082 by guarding against a new case of malformed invocation not previously covered. r? @alexcrichton
-
由 Manish Goregaokar 提交于
Rewrite `collections::LinkedList::append` doc example. None
-
由 Manish Goregaokar 提交于
Revert "Remove unused methods from MultiSpan" This reverts commit f7019a4e. That commit removed the only way to make a suggestion with more than one substitute. That feature is not used directly by rustc but exists and is used by Clippy. Bring it back until we come up with a better solution (suggestions don't use span labels, so it would make sense for them to use their own type). Rational there: https://github.com/Manishearth/rust-clippy/pull/1119. r? @jonathandturner Cc @Manishearth
-
由 Manish Goregaokar 提交于
intravisit: Fold functionality of IdVisitor into the regular Visitor.
-
由 Manish Goregaokar 提交于
Rename _ to {integer} and {float} for unknown numeric types This PR renames _ to {integer} or {float} for unknown numeric types, to help people parse error messages that have numeric types that haven't been nailed down. Example: ```rust fn main() { let x: String = 4; } ``` Before: ``` error[E0308]: mismatched types --> quicktest.rs:2:21 | 2 | let x: String = 4; | ^ expected struct `std::string::String`, found integral variable | = note: expected type `std::string::String` = note: found type `_` error: aborting due to previous error ``` after: ``` error[E0308]: mismatched types --> quicktest.rs:2:21 | 2 | let x: String = 4; | ^ expected struct `std::string::String`, found integral variable | = note: expected type `std::string::String` = note: found type `{integer}` error: aborting due to previous error ``` ```
-
由 Manish Goregaokar 提交于
resolve: Exclude inaccessible names from single imports If a single import resolves to an inaccessible name in some but not all namespaces, avoid importing the name in the inaccessible namespaces. Currently, the inaccessible namespaces are imported but cause a privacy error when used. r? @nrc
-
由 Manish Goregaokar 提交于
Add non-panicking abs() functions to all signed integer types. Currently, calling abs() on one of the signed integer types might panic (in debug mode at least) because the absolute value of the largest negative value can not be represented in that signed type. Unlike all other integer operations, there is currently not a non-panicking version on this function. This seems to just be an oversight in the design, therefore just adding it now.
-
由 Manish Goregaokar 提交于
Add a test for AddAssign on String Fix #35047
-