- 21 11月, 2016 1 次提交
-
-
由 Jeffrey Seyfried 提交于
-
- 20 11月, 2016 8 次提交
-
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 bors 提交于
Show a better error when using --test with #[proc_macro_derive] Fixes https://github.com/rust-lang/rust/issues/37480 Currently using `--test` with a crate that contains a `#[proc_macro_derive]` attribute causes an error. This PR doesn't attempt to fix the issue itself, or determine what tesing of a proc_macro_derive crate should be - just to provide a better error message.
-
由 bors 提交于
rustbuild: allow dynamically linking LLVM The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to find out if LLVM defaulted to shared or static libraries, and just went with that. But under rustbuild, `librustc_llvm/build.rs` was assuming that LLVM should be static, and even forcing `--link-static` for 3.9+. Now that build script also uses `--shared-mode` to learn the default, which should work better for pre-3.9 configured for dynamic linking, as it wasn't possible back then to choose differently via `llvm-config`. Further, the configure script now has a new `--enable-llvm-link-shared` option, which allows one to manually override `--link-shared` on 3.9+ instead of forcing static. Update: There are now four static/shared scenarios that can happen for the supported LLVM versions: - 3.9+: By default use `llvm-config --link-static` - 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead. - 3.8: Use `llvm-config --shared-mode` and go with its answer. - 3.7: Just assume static, maintaining the status quo.
-
- 19 11月, 2016 13 次提交
-
-
由 bors 提交于
fix `extern "aapcs" fn` to actually use the AAPCS calling convention closes #37810 This is technically a [breaking-change] because it changes the ABI of `extern "aapcs"` functions that (a) involve `f32`/`f64` arguments/return values and (b) are compiled for arm-eabihf targets from "aapcs-vfp" (wrong) to "aapcs" (correct). Appendix: What these ABIs mean? - In the "aapcs-vfp" ABI or "hard float" calling convention: Floating point values are passed/returned through FPU registers (s0, s1, d0, etc.) - Whereas, in the "aapcs" ABI or "soft float" calling convention: Floating point values are passed/returned through general purpose registers (r0, r1, etc.) Mixing these ABIs can cause problems if the caller assumes that the routine is using one of these ABIs but it's actually using the other one. --- r? @alexcrichton We are going this `extern "aapcs" fn` thing to implement some intrinsics (floatundidf) for the eabihf targets in order to comply with LLVM's calling convention of intrinsics. Oh, and the value of the enum came from [here](http://llvm.org/docs/doxygen/html/namespacellvm_1_1CallingConv.html). cc @TimNN @parched
-
由 bors 提交于
instantiate closures on demand this should fix compilation with `-C codegen-units=4` - tested locally with `RUSTFLAGS='-C codegen-units=4' ../x.py test` r? @michaelwoerister
-
由 bors 提交于
fix travis: update Cargo.lock
-
由 bors 提交于
ICH: Handle MacroDef HIR instances. As of recently, `hir::MacroDef` instances are exported in crate metadata, which means we also store their ICH when doing incremental compilation. Even though exported macro definitions should not (yet) interact with incremental compilation, the ICH is also used for the general purpose crate hash, where macros should be included. This PR implements ICH computation for `MacroDef`. In theory, the ICH of these MacroDefs is less stable than that of other HIR items, since I opted to just call the compiler-generated `Hash::hash()` for `Token::Interpolated` variants. `Token::Interpolated` contains AST data structures and it would have been a lot of effort to expand ICH computation to the AST too. Since quasi-quoting is rarely used *and* it would only make a difference if incremental compilation was extended to macros, the simpler implementation seemed like a good idea. This fixes the problem reported in https://github.com/rust-lang/rust/issues/37756. The test still fails because of broken codegen-unit support though. r? @nikomatsakis
-
由 bors 提交于
Don't build the lexer verifier during tidy Tidy is not the right place to do this. Tidy is for running lints. We should instead be running the lexer/grammar tests as part of the test suite. This may fix nightly breakage, but I don't understand why. https://buildbot.rust-lang.org/builders/nightly-dist-rustc-linux/builds/715/steps/distcheck/logs/stdio r? @alexcrichton cc @dns2utf8
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Brian Anderson 提交于
Tidy is not the right place to do this. Tidy is for running lints. We should instead be running the lexer/grammar tests as part of the test suite. This may fix nightly breakage, but I don't know why.
-
由 bors 提交于
save-analysis: handle << and >> operators inside [] in types Fixes #37700
-
由 bors 提交于
Improvements to the #[should_panic] feature Add more error checking for the `#[should_panic]` attribute, and print the expected panic string when it does not match. Fixes https://github.com/rust-lang/rust/issues/29000 Eg: ```running 3 tests test test2 ... ok test test1 ... FAILED : Panic did not include expected string 'foo' test test3 ... FAILED failures: ---- test1 stdout ---- thread 'test1' panicked at 'bar', test.rs:7 note: Run with `RUST_BACKTRACE=1` for a backtrace. ---- test3 stdout ---- thread 'test3' panicked at 'bar', test.rs:18 ```
-
- 18 11月, 2016 18 次提交
-
-
由 bors 提交于
rustbuild: Allow configuration of python interpreter Add a configuration key to `config.toml`, read it from `./configure`, and add auto-detection if none of those were specified. Closes #35760
-
由 Tim Neumann 提交于
-
由 Josh Driver 提交于
-
由 Ariel Ben-Yehuda 提交于
this should fix compilation with `-C codegen-units=4` - tested locally with `RUSTFLAGS='-C codegen-units=4' ../x.py test`
-
由 bors 提交于
rustdoc: add cli argument `--playground-url` Add a new cli argument `--playground-url` for rustdoc: `rustdoc lib.rs --playground-url="https://play.rust-lang.org/"` `rustdoc book.md --playground-url="https://play.rust-lang.org/"` This makes it possible for tools like https://docs.rs to generate crate docs that can submit samples code to run at https://play.rust-lang.org, even if the crate's author *forgot* putting `#![doc(html_playground_url = "https://play.rust-lang.org/")]` to crate root. By the way, I'd like to say, many crate authors are not aware of existing of `#![doc(html_playground_url = "https://play.rust-lang.org/")]`. `--playground-url` may be reset by `--markdown-playground-url` or `#![doc(html_playground_url=...)]`, so it's backward compatible. @alexcrichton since you implemented playground-url related features.
-
由 Josh Stone 提交于
There are now four static/shared scenarios that can happen for the supported LLVM versions: - 3.9+: By default use `llvm-config --link-static` - 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead. - 3.8: Use `llvm-config --shared-mode` and go with its answer. - 3.7: Just assume static, maintaining the status quo.
-
由 bors 提交于
Fix bug in proc_macro dependency loading Fixes #37839. r? @alexcrichton
-
由 bors 提交于
Separate impl items from the parent impl This change separates impl item bodies out of the impl itself. This gives incremental more resolution. In so doing, it refactors how the visitors work, and cleans up a bit of the collect/check logic (mostly by moving things out of collect that didn't really belong there, because they were just checking conditions). However, this is not as effective as I expected, for a kind of frustrating reason. In particular, when invoking `foo.bar()` you still wind up with dependencies on private items. The problem is that the method resolution code scans that list for methods with the name `bar` -- and this winds up touching *all* the methods, even private ones. I can imagine two obvious ways to fix this: - separating fn bodies from fn sigs (#35078, currently being pursued by @flodiebold) - a more aggressive model of incremental that @michaelwoerister has been advocating, in which we hash the intermediate results (e.g., the outputs of collect) so that we can see that the intermediate result hasn't changed, even if a particular impl item has changed. So all in all I'm not quite sure whether to land this or not. =) It still seems like it has to be a win in some cases, but not with the test cases we have just now. I can try to gin up some test cases, but I'm not sure if they will be totally realistic. On the other hand, some of the early refactorings to the visitor trait seem worthwhile to me regardless. cc #36349 -- well, this is basically a fix for that issue, I guess r? @michaelwoerister NB: Based atop of @EddyB's PR https://github.com/rust-lang/rust/pull/37402; don't land until that lands.
-
由 Jeffrey Seyfried 提交于
-
由 Nick Cameron 提交于
Fixes #37700
-
由 Jeffrey Seyfried 提交于
-
由 bors 提交于
Improved error reporting when target sysroot is missing. Attempts to resolve #37131. This is my first pull request on rust, so I would greatly appreciate any feedback you have on this. Thanks!
-
由 Niko Matsakis 提交于
-
由 bors 提交于
Rollup of 8 pull requests - Successful merges: #37752, #37757, #37759, #37766, #37772, #37799, #37806, #37821 - Failed merges: #37442
-
由 Niko Matsakis 提交于
This sidesteps problems with long paths because the canonical path includes the "magic long path prefix" on Windows.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
(Unrelated to this PR series)
-
由 Niko Matsakis 提交于
Also simplify some of the `ty::AssociatedItem` representation, in particular by folding `has_value` into `hir::Defaultness`
-