| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 6810f5286b6b91daab06fc3dccb27d8c46f14349, reversing
changes made to 8586ec6980462c99a8926646201b2444d8938d29.
|
|
Munksgaard:better-error-message-in-no_lookup_host_duplicates, r=alexcrichton
Improve output if no_lookup_host_duplicates test fails
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
|
|
Move std::os::raw::c_void into libcore and re-export in libstd
Implements the first part of [RFC 2521](https://github.com/rust-lang/rfcs/pull/2521).
cc #53856
|
|
fix some uses of pointer intrinsics with invalid pointers
[Found by miri](https://github.com/solson/miri/pull/446):
* `Vec::into_iter` calls `ptr::read` (and the underlying `copy_nonoverlapping`) with an unaligned pointer to a ZST. [According to LLVM devs](https://bugs.llvm.org/show_bug.cgi?id=38583), this is UB because it contradicts the metadata we are attaching to that pointer.
* `HashMap` creation calls `ptr:.write_bytes` on a NULL pointer with a count of 0. This is likely not currently UB *currently*, but it violates the rules we are setting in https://github.com/rust-lang/rust/pull/53783, and we might want to exploit those rules later (e.g. with more `nonnull` attributes for LLVM).
Probably what `HashMap` really should do is use `NonNull::dangling()` instead of 0 for the empty case, but that would require a more careful analysis of the code.
It seems like ideally, we should do a review of usage of such intrinsics all over libstd to ensure that they use valid pointers even when the size is 0. Is it worth opening an issue for that?
|
|
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
|
|
|
|
re-mark the never docs as unstable
Fixes https://github.com/rust-lang/rust/issues/54198
This stability attribute was removed in https://github.com/rust-lang/rust/pull/47630, but not replaced with a `#[stable]` attribute, and when https://github.com/rust-lang/rust/pull/50121 reverted that stabilization, it didn't set the docs back to unstable. I'm concerned as to why it was allowed to not have the stability attribute at all, but at least this can put it back.
I'm nominating this for beta backport because it's a really small change, and right now our docs are in an awkward position where the `!` type is technically unstable to use, but the docs don't say so the same way any other library feature would. (And this is also the case *on stable* now, but i'm not suggesting a stable backport for a docs fix.)
|
|
Fix the stable release of os_str_str_ref_eq
This was added and stabilized in commit 02503029b83a, but while that
claimed to be for 1.28.0, it didn't actually make it until 1.29.0.
Fixes #54195.
|
|
Remove println!() statement from HashMap unit test
|
|
Rollup of 11 pull requests
Successful merges:
- #53371 (Do not emit E0277 on incorrect tuple destructured binding)
- #53829 (Add rustc SHA to released DWARF debuginfo)
- #53950 (Allow for opting out of ThinLTO and clean up LTO related cli flag handling.)
- #53976 (Replace unwrap calls in example by expect)
- #54070 (Add Error::description soft-deprecation to RELEASES)
- #54076 (miri loop detector hashing)
- #54119 (Add some unit tests for find_best_match_for_name)
- #54147 (Add a test that tries to modify static memory at compile-time)
- #54150 (Updated 1.29 release notes with --document-private-items flag)
- #54163 (Update stage 0 to latest beta)
- #54170 (COMPILER_TESTS.md has been moved)
|
|
|
|
This was added and stabilized in commit 02503029b83a, but while that
claimed to be for 1.28.0, it didn't actually make it until 1.29.0.
|
|
|
|
|
|
Add rustc SHA to released DWARF debuginfo
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
|
|
Replace unwrap calls in example by expect
Part of #51668.
r? @steveklabnik
|
|
Add target thumbv7a-pc-windows-msvc
This is an early draft of support for Windows/ARM. To test it,
1. Install Visual Studio 2017 and Windows SDK version 17134.
1. Obtain alexcrichton/xz2-rs#35, rust-lang-nursery/compiler-builtins#256, and the fix for [LLVM Bug 38620](https://bugs.llvm.org/show_bug.cgi?id=38620).
2. Open a command prompt and run
```
set CC_thumbv7a-pc-windows-msvc=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\CL.exe
set CFLAGS_thumbv7a-pc-windows-msvc=/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /nologo
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc
```
It will build the stage 2 compiler, but fail building stage 2 test. To build an executable targeting windows/arm,
1. Copy `build\x86_64-pc-windows-msvc\stage0\bin\cargo.exe` to `build\x86_64-pc-windows-msvc\stage2\bin`
2. Open a command prompt and run
```
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set PATH=build\x86_64-pc-windows-msvc\stage2\bin;%PATH%
cargo new hello
cd hello
cargo build --target thumbv7a-pc-windows-msvc –release
```
Copy target\thumbv7a-pc-windows-msvc\release\hello.exe to your platform and run.
There are a number of open issues that I'm hoping to get help with:
- Error when compiling the `test` crate: `error: cannot link together two panic runtimes: panic_abort and panic_unwind`
- Warnings when building the compiler_builtins crate: `warning: cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'`. It looks like the build system is passing GCC-style flags to MSVC.
- How to specify the LIBPATH entries for ARM. Right now they are hardcoded as absolute paths in the target spec.
This pull request depends on
- alexcrichton/xz2-rs#35 - update vcxproj to Visual Studio 2017
- rust-lang-nursery/compiler-builtins#256 - fix compile errors when building for windows/arm
- [Bug 38620 - ARM: Incorrect COFF relocation type for thumb bl instruction](https://bugs.llvm.org/show_bug.cgi?id=38620)
This PR updates #52659
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Fix typos in libstd hash map
modified growth algo description to read "the first table overflows into the second, and the second into the first." plus smaller typos
|
|
`&CStr`, not `CStr`, is the counterpart of `&str`
|
|
Update documentation for fill_buf in std::io::BufRead
Brings the documentation in line with the BufReader implementation.
Fixes #48022.
This is my first PR, and I think the `E-easy` label is very cool, as so is the practice of describing the fix but leaving it for someone else; it really makes it a lot less intimidating to get started with something!
|
|
Co-authored-by: nikomatsakis
|
|
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
|
|
modified to read "the first table overflows into the second, and the second into the first." plus smaller typos
|
|
closes #40289
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #53315 (use `NonZeroU32` in `newtype_index!`macro, change syntax)
- #53932 ([NLL] Remove base_place)
- #53942 (Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.)
- #53973 (Have rust-lldb look for the rust-enabled lldb)
- #53981 (Implement initializer() for FileDesc)
- #53987 (rustbuild: allow configuring llvm version suffix)
- #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.)
- #54007 (crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint)
- #54040 (update books for next release)
- #54050 (Update `petgraph` dependency to 0.4.13 to fix build with nightly)
|
|
Implement initializer() for FileDesc
Here was my initial issue:
```rust
use std::process::{Command};
fn main() {
let output = Command::new("curl").arg("-s").arg("http://ovh.net/files/100Mio.dat").output();
println!("{:?}", output.unwrap().stdout.len());
}
```
```
~/stuff ❯❯❯ time ./dwl
104857600
./dwl 16.22s user 1.80s system 23% cpu 1:15.24 total
```
```rust
use std::process::{Command, Stdio};
fn main() {
let child = Command::new("curl").arg("-s").arg("http://ovh.net/files/100Mio.dat").stdout(Stdio::piped()).spawn();
let output = child.unwrap().wait_with_output().unwrap();
println!("{:?}", output.stdout.len());
}
```
```
~/stuff ❯❯❯ time ./dwl2
104857600
./dwl2 0.64s user 2.18s system 5% cpu 53.072 total
```
As you can see the first version is spending much more time in userland and also uses more cpu. With the help of @programble, @talchas and @habnabit on the rust IRC, we discovered that the slow version uses two pipes, one for `stdin` and one for `stderr` and in that case it polls when going through [this function](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/pipe.rs#L82). The polling calls `read_to_end` on the pipes repetitively and this results in zeroing its internal buffer each time. To avoid this zeroing, `FileDesc` needs to implement `initializer`. We see no reason why it [wouldn't work with uninitialized memory](https://doc.rust-lang.org/1.26.1/src/std/io/mod.rs.html#534) so this PR fixes that.
Here is some tracing of the slow program:
versus the fast program:
I have not tested the change yet but will try to build it tomorrow.
|
|
stabilize #[panic_handler]
closes #44489
### Update(2018-09-07)
This was proposed for stabilization in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881 and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in https://github.com/rust-lang/rust/issues/44489#issuecomment-416645946
Documentation PRs:
- Reference. https://github.com/rust-lang-nursery/reference/pull/362
- Nomicon. https://github.com/rust-lang-nursery/nomicon/pull/75
---
`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.
(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054
Some unresolved questions from #44489:
> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".
The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.
> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?
I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?
---
Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.
cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
|
|
r=Mark-Simulacrum,QuietMisdreavus
Trait impl show docs
Fixes #51834.
<img width="1440" alt="screen shot 2018-06-29 at 00 14 33" src="https://user-images.githubusercontent.com/3050060/42063323-6e6e8cc8-7b31-11e8-88ef-4dd2229df76c.png">
(You can see both commit changes in the screenshot 😄)
r? @QuietMisdreavus
|
|
Brings the documentation in line with the BufReader implementation.
Fixes #48022.
|
|
|
|
|
|
Cross reference io::copy and fs::copy in docs.
Fixes https://github.com/rust-lang/rust/issues/52524.
|
|
|
|
|
|
in order to avoid constantly zeroing memory when it's not needed.
|
|
|
|
Update Cargo.lock
This also includes major version bumps for the rand crate used by core, std, and alloc tests, among other crates (regex, etc.) used elsewhere. Since these are all internal there should be no user-visible changes.
r? @alexcrichton
|
|
Allow to check if sync::Once is already initialized
Hi!
I propose to expose a way to check if a `Once` instance is initialized.
I need it in `once_cell`. `OnceCell` is effetively a pair of `(Once, UnsafeCell<Option<T>>)`, which can set the `T` only once. Because I can't check if `Once` is initialized, I am forced to add an indirection and check the value of ptr instead:
https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L423-L429
https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L457-L461
The `parking_lot`'s version of `Once` exposes the state as an enum: https://docs.rs/parking_lot/0.6.3/parking_lot/struct.Once.html#method.state.
I suggest, for now, just to add a simple `bool` function: this fits my use-case perfectly, exposes less implementation details, and is forward-compatible with more fine-grained state checking.
|
|
|
|
|
|
Reduce number of syscalls in `rand`
This skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
|
|
|
|
Add Error::source method per RFC 2504.
This implements part of RFC 2504.
* Adds `Error::source`, a replacement for `Error::cause` with the "right" signature, which will be instantly stable.
* Deprecates `Error::cause` in 1.33 (this choice was based on the precedent in #52994, which we haven't finalized).
* Redefines `Error::cause` to delegate to `Error::source` (the delegation can only go in this direction, not the other).
@rfcbot fcp merge
|
|
Rollup of 9 pull requests
Successful merges:
- #53076 (set cfg(rustdoc) when rustdoc is running on a crate)
- #53622 (cleanup: Add main functions to some UI tests)
- #53769 (Also link Clippy repo in the CONTRIBUTING.md file)
- #53774 (Add rust-gdbgui script.)
- #53781 (bench: libcore: fix build failure of any.rs benchmark (use "dyn Any"))
- #53782 (Make Arc cloning mechanics clearer in module docs)
- #53790 (Add regression test for issue #52060)
- #53801 (Prevent duplicated impl on foreign types)
- #53850 (Nuke the `const_to_allocation` query)
|
|
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
|
|
|
|
|
|
|
