- 08 5月, 2017 7 次提交
-
-
由 Michael Woerister 提交于
-
由 bors 提交于
Add support for Hexagon v60 HVX intrinsics HVX is a SIMD coprocessor available on newer hexagon cores. It can be configured for 512 or 1024 bit registers, and some instructions use pairs of registers. It only does integer operations, but it probably has every integer operation you'd want for 8/16/32 bit elements. There are a lot of intrinsics. The generator outputs 582 of them. I probably got some wrong. I did some scripting to make sure that every llvm intrinsic name exists, but intrinsic names provided for programs have only been compared by eye to Qualcomm's own names. 64/128 is also appended to the names to select between 512/1024 bit. The C intrinsics don't do this, but they only expose one set, selected at compile time. The json specifying the intrinsics required a bit of duplication since I didn't see an easy way to specify combinations of signed/unsigned types (eg. u(8-16) and s(16-32)). I also didn't see an easy way to specify variants of instructions like saturating or rounding. Basic multiplication and load/store tested on the hexagon simulator.
-
由 bors 提交于
Delete features which are easily removed, in libsyntax
-
由 Michael Wu 提交于
-
由 bors 提交于
[DOC] Improve `thread::panicking` documentaion. Part of #29378 Takes care of: `panicking` could use some more advice on when to use this. I mays have done a poor choice of introducing `Mutex`s. r? @steveklabnik
-
由 Felix Raimundo 提交于
Part of #29378
-
由 bors 提交于
Minor cleanup of UX guidelines. I think this fixes https://github.com/rust-lang/rust/issues/34808. It covers the [long error code explanations normalization] by linking to the RFC, and cleaning up the list where long diagnostics are defined. While the [error message overhaul] isn't covered directly, I'm not really sure that more than the [existing section] on the error/warning/help messages is warranted; the overhaul linked didn't really specify any new guidelines, primarily just changing the output format. [Long error code explanations normalization]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md [Error message overhaul]: https://github.com/rust-lang/rust/issues/33240 [existing section]: https://github.com/rust-lang/rust/blob/master/src/doc/rustc-ux-guidelines.md#error-warning-help-note-messages
-
- 07 5月, 2017 13 次提交
-
-
由 bors 提交于
Point at fields that make the type recursive On recursive types of infinite size, point at all the fields that make the type recursive. ```rust struct Foo { bar: Bar, } struct Bar { foo: Foo, } ``` outputs ``` error[E0072]: recursive type `Foo` has infinite size --> file.rs:1:1 1 | struct Foo { | ^^^^^^^^^^ recursive type has infinite size 2 | bar: Bar, | -------- recursive here | = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable error[E0072]: recursive type `Bar` has infinite size --> file.rs:5:1 | 5 | struct Bar { | ^^^^^^^^^^ recursive type has infinite size 6 | foo: Foo, | -------- recursive here | = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Bar` representable ```
-
由 bors 提交于
Allow # to appear in rustdoc code output. "##" at the start of a trimmed rustdoc line is now cut to "#" and then shown. If the user wanted to show "##", they can type "###". I'm somewhat concerned about the potential implications for users, since this does make a potentially backwards-incompatible change. Previously, `##` had no special handling, and now we do change it. However, I'm not really sure what we can do here to improve this, and I can't think of any cases where `##` would likely be correct in a code block, though of course I could be wrong. Fixes #41783.
-
由 bors 提交于
Add links between `slice::{copy,clone}_from_slice` in docs. None
-
由 ubsan 提交于
-
由 bors 提交于
Increase macro recursion limit to 1024 Fixes #22552
-
由 bors 提交于
Fix issue #41652 Fix issue #41652. Don't print anything in `render_source_line()` if no source code is given. (cc @jonathandturner #34789)
-
由 Mark Simulacrum 提交于
"##" at the start of a trimmed rustdoc line is now cut to "#" and then shown. If the user wanted to show "##", they can type "###".
-
由 bors 提交于
Fix definitions of ULONG_PTR The Windows type `ULONG_PTR` is supposed to be equivalent to `usize`, but several parts of the codebase currently define it as `u64`. Evidently this hasn't broken anything yet but it might cause annoying 32-bit-specific breakage in future. See https://msdn.microsoft.com/en-gb/library/windows/desktop/aa383751(v=vs.85).aspx r? @alexcrichton
-
由 Mark Simulacrum 提交于
-
由 bors 提交于
Fix "an" usage Since the pr i reviewed on got merged way before the author had a chance to quickly change it, i just did it myself. (Or well, someone else asked me to, if you want me to be honest)
-
由 bors 提交于
Trigger llvm rebuild This was missing from #41739, thanks @tedhorst for noticing!
-
由 Corey Farwell 提交于
-
由 acdenisSK 提交于
-
- 06 5月, 2017 19 次提交
-
-
由 Tim Neumann 提交于
-
由 Joshua Sheard 提交于
-
由 acdenisSK 提交于
-
由 Esteban Küber 提交于
-
由 bors 提交于
Add an example to std::thread::Result type This PR is a part of https://github.com/rust-lang/rust/issues/29378. I submit this PR with the help (mentoring) of @steveklabnik. I'm still not sure my request is good enough but I don't want to spoil the issue with too much questions so I continue here. r? @steveklabnik
-
由 bors 提交于
Rollup of 9 pull requests - Successful merges: #41064, #41307, #41512, #41582, #41678, #41722, #41734, #41761, #41763 - Failed merges:
-
由 Corey Farwell 提交于
Move unicode Python script into libstd_unicode crate. The only place this Python script is used is inside the libstd_unicode crate, so lets move it there.
-
由 Corey Farwell 提交于
Add regression test for issue #24106 Fixes #24106.
-
由 Corey Farwell 提交于
Refactor variance and remove last `[pub]` map This PR refactors variance to work in a more red-green friendly way. Because red-green doesn't exist yet, it has to be a bit hacky. The basic idea is this: - We compute a big map with the variance for all items in the crate; when you request variances for a particular item, we read it from the crate - We now hard-code that traits are invariant (which they are, for deep reasons, not gonna' change) - When building constraints, we compute the transitive closure of all things within the crate that depend on what using `TransitiveRelation` - this lets us gin up the correct dependencies when requesting variance of a single item Ah damn, just remembered, one TODO: - [x] Update the variance README -- ah, I guess the README updates I did are sufficient r? @michaelwoerister
-
由 Corey Farwell 提交于
Suggest `!` for bitwise negation when encountering a `~` Fix #41679 Here is a program ```rust fn main() { let x = ~1; } ``` It's output: ``` error: `~` can not be used as an unary operator --> /home/fcc/temp/test.rs:4:13 | 4 | let x = ~1; | ^^ | = help: use `!` instead of `~` if you meant to bitwise negation ``` cc @bstrie
-
由 Corey Farwell 提交于
Add option to display warnings in rustdoc Part of #41574. r? @alexcrichton The output for this file: ```rust /// ``` /// fn foo(x: u32) {} /// /// foo(2); /// let x = 1; /// panic!(); /// ``` fn foo() {} /// ``` /// fn foo(x: u32) {} /// /// foo(2); /// let x = 1; /// ``` fn foo2() {} /// ``` /// fn foo(x: u32) {} /// /// foo(2); /// let x = 1; /// panic!(); /// ``` fn foo3() {} fn main() { } ``` is the following: ``` > ./build/x86_64-apple-darwin/stage1/bin/rustdoc -Z unstable-options --display-warnings --test test.rs running 3 tests test test.rs - foo (line 1) ... FAILED test test.rs - foo3 (line 18) ... FAILED test test.rs - foo2 (line 10) ... ok successes: ---- test.rs - foo2 (line 10) stdout ---- warning: unused variable: `x` --> <anon>:2:8 | 2 | fn foo(x: u32) {} | ^ | = note: #[warn(unused_variables)] on by default warning: unused variable: `x` --> <anon>:5:5 | 5 | let x = 1; | ^ | = note: #[warn(unused_variables)] on by default successes: test.rs - foo2 (line 10) failures: ---- test.rs - foo (line 1) stdout ---- warning: unused variable: `x` --> <anon>:2:8 | 2 | fn foo(x: u32) {} | ^ | = note: #[warn(unused_variables)] on by default warning: unused variable: `x` --> <anon>:5:5 | 5 | let x = 1; | ^ | = note: #[warn(unused_variables)] on by default thread 'rustc' panicked at 'test executable failed: thread 'main' panicked at 'explicit panic', <anon>:6 note: Run with `RUST_BACKTRACE=1` for a backtrace. ', src/librustdoc/test.rs:317 note: Run with `RUST_BACKTRACE=1` for a backtrace. ---- test.rs - foo3 (line 18) stdout ---- warning: unused variable: `x` --> <anon>:2:8 | 2 | fn foo(x: u32) {} | ^ | = note: #[warn(unused_variables)] on by default warning: unused variable: `x` --> <anon>:5:5 | 5 | let x = 1; | ^ | = note: #[warn(unused_variables)] on by default thread 'rustc' panicked at 'test executable failed: thread 'main' panicked at 'explicit panic', <anon>:6 note: Run with `RUST_BACKTRACE=1` for a backtrace. ', src/librustdoc/test.rs:317 failures: test.rs - foo (line 1) test.rs - foo3 (line 18) test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured ```
-
由 Corey Farwell 提交于
Reload nameserver information on lookup failure As discussed in #41570, UNIX systems often cache the contents of `/etc/resolv.conf`, which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd. Fixes #41570. Depends on rust-lang/libc#585. r? @alexcrichton
-
由 Corey Farwell 提交于
std: Avoid locks during TLS destruction on Windows Gecko recently had a bug reported [1] with a deadlock in the Rust TLS implementation for Windows. TLS destructors are implemented in a sort of ad-hoc fashion on Windows as it doesn't natively support destructors for TLS keys. To work around this the runtime manages a list of TLS destructors and registers a hook to get run whenever a thread exits. When a thread exits it takes a look at the list and runs all destructors. Unfortunately it turns out that there's a lock which is held when our "at thread exit" callback is run. The callback then attempts to acquire a lock protecting the list of TLS destructors. Elsewhere in the codebase while we hold a lock over the TLS destructors we try to acquire the same lock held first before our special callback is run. And as a result, deadlock! This commit sidesteps the issue with a few small refactorings: * Removed support for destroying a TLS key on Windows. We don't actually ever exercise this as a public-facing API, and it's only used during `lazy_init` during racy situations. To handle that we just synchronize `lazy_init` globally on Windows so we never have to call `destroy`. * With no need to support removal the global synchronized `Vec` was tranformed to a lock-free linked list. With the removal of locks this means that iteration no long requires a lock and as such we won't run into the deadlock problem mentioned above. Note that it's still a general problem that you have to be extra super careful in TLS destructors. For example no code which runs a TLS destructor on Windows can call back into the Windows API to do a dynamic library lookup. Unfortunately I don't know of a great way around that, but this at least fixes the immediate problem that Gecko was seeing which is that with "well behaved" destructors the system would still deadlock! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1358151
-
由 Corey Farwell 提交于
Remove jquery dependency r? @rust-lang/docs Fixes #39159.
-
由 Corey Farwell 提交于
refactor NonZero, Shared, and Unique APIs Major difference is that I removed Deref impls, as apparently LLVM has trouble maintaining metadata with a `&ptr -> &ptr` API. This was cited as a blocker for ever stabilizing this API. It wasn't that ergonomic anyway. * Added `get` to NonZero to replace Deref impl * Added `ptr` getter to Shared/Unique to replace Deref impl * Added Unique's `get` and `get_mut` conveniences to Shared * Deprecated `as_mut_ptr` on Shared in favour of `ptr` Note that Shared used to primarily expose only `*const` but there isn't a good justification for that, so I made it `*mut`.
-
由 bors 提交于
std: Prevent deadlocks in doctests on Windows Windows historically has problems with threads panicking and the main thread exiting at the same time, typically causing deadlocks. In the past (#25824) we've joined on threads but this just prevents running the test for now to avoid tampering with the example.
-
由 Niko Matsakis 提交于
-
由 Alex Crichton 提交于
Windows historically has problems with threads panicking and the main thread exiting at the same time, typically causing deadlocks. In the past (#25824) we've joined on threads but this just prevents running the test for now to avoid tampering with the example.
-
由 bors 提交于
Update rust-installer to fix rust-lang-nursery/rustup.rs#1092 r? @TimNN cc @alexcrichton @ranma42
-
- 05 5月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
Gecko recently had a bug reported [1] with a deadlock in the Rust TLS implementation for Windows. TLS destructors are implemented in a sort of ad-hoc fashion on Windows as it doesn't natively support destructors for TLS keys. To work around this the runtime manages a list of TLS destructors and registers a hook to get run whenever a thread exits. When a thread exits it takes a look at the list and runs all destructors. Unfortunately it turns out that there's a lock which is held when our "at thread exit" callback is run. The callback then attempts to acquire a lock protecting the list of TLS destructors. Elsewhere in the codebase while we hold a lock over the TLS destructors we try to acquire the same lock held first before our special callback is run. And as a result, deadlock! This commit sidesteps the issue with a few small refactorings: * Removed support for destroying a TLS key on Windows. We don't actually ever exercise this as a public-facing API, and it's only used during `lazy_init` during racy situations. To handle that we just synchronize `lazy_init` globally on Windows so we never have to call `destroy`. * With no need to support removal the global synchronized `Vec` was tranformed to a lock-free linked list. With the removal of locks this means that iteration no long requires a lock and as such we won't run into the deadlock problem mentioned above. Note that it's still a general problem that you have to be extra super careful in TLS destructors. For example no code which runs a TLS destructor on Windows can call back into the Windows API to do a dynamic library lookup. Unfortunately I don't know of a great way around that, but this at least fixes the immediate problem that Gecko was seeing which is that with "well behaved" destructors the system would still deadlock! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1358151
-