| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #43923.
|
|
This reverts commit 309ab478d31a699493fdb1593d9cb133705f51f0.
|
|
|
|
|
|
zackmdavis:missing_sum_and_product_for_128_bit_integers, r=nagisa
add u128/i128 to sum/product implementors
Resolves #43235.
|
|
macros: fix regression involving identifiers in `macro_rules!` patterns.
Fixes #42019.
r? @nrc
|
|
support pub(restricted) in thread_local! (round 2)
Resurrected #40984 now that the issue blocking it was fixed. Original description:
`pub(restricted)` was stabilized in #40556 so let's go!
Here is a [playground](https://play.rust-lang.org/?gist=f55f32f164a6ed18c219fec8f8293b98&version=nightly&backtrace=1).
I changed the interface of `__thread_local_inner!`, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.
|
|
Resolves #43235.
|
|
|
|
Add regression tests to ensure stable drop order
Work towards #43034
I think this is all we need to do on the testing front regarding RFC 1857
|
|
Thread local try with
https://github.com/rust-lang/rfcs/pull/2030 was turned into this PR (the RFC was closed, but it looks like just a PR should be good).
See also: state stabilization issue: #27716
`try_with` is used in two places in std: stdio and thread_info. In stdio, it would be better if the result was passed to the closure, but in thread_info, it's better as is where the result is returned from the function call. I'm not sure which is better, but I prefer the current way as it better represents the scope.
|
|
|
|
Implement Eq/Hash/Debug etc. for unsized tuples.
As I mentioned in [the comment in #18469](https://github.com/rust-lang/rust/issues/18469#issuecomment-306767422), the implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, `Debug`, `Hash` can be generalized to unsized tuples.
This is consistent with the `derive` behavior for unsized structs.
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Default, Hash)]
struct MyTuple<X, Y, Z: ?Sized>(X, Y, Z);
fn f(x: &MyTuple<i32, i32, [i32]>) {
x == x;
x < x;
println!("{:?}", x);
}
```
Questions:
- Need an RFC?
- Need a feature gate? I don't think it does because the unsized tuple coercion #42527 is feature-gated.
- I changed `builder.field($name);` into `builder.field(&$name);` in the `Debug` implementation to pass compilation. This won't affect the behavior because `Debug for &'a T` is a mere redirection to `Debug for T`. However, I don't know if it affects code size / performance.
|
|
|
|
|
|
Prepare for `normalize-std???` which will share the same logic.
Added `ignore-32bit` and `ignore-64bit`.
|
|
Only match a fragment specifier the if it starts with certain tokens.
When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838).
In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future.
Fixes #24189.
Fixes #26444.
Fixes #27832.
Fixes #34030.
Fixes #35650.
Fixes #39964.
Fixes the 4th comment in #40569.
Fixes the issue blocking #40984.
|
|
|
|
|
|
|
|
|
|
Fix some tests on Linux
|
|
|
|
remove associated_consts feature gate
Currently struggling to run tests locally (something about jemalloc target missing).
cc #29646
|
|
Fixes #24189.
Fixes #26444.
Fixes #27832.
Fixes #34030.
Fixes #35650.
Fixes #39964.
Fixes the 4th comment in #40569.
Fixes the issue blocking #40984.
|
|
|
|
|
|
This commit implements stack probes on x86/x86_64 using the freshly landed
support upstream in LLVM. The purpose of stack probes here are to guarantee a
segfault on stack overflow rather than having a chance of running over the guard
page already present on all threads by accident.
At this time there's no support for any other architecture because LLVM itself
does not have support for other architectures.
|
|
Switch to rust-lang-nursery/compiler-builtins
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
|
|
rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
|
|
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
|
|
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
|
|
|
|
Replacement: 41439
Deprecation: 42310 for 1.19
Fixes 41477
|
|
Improve tests and benchmarks for slice::sort and slice::sort_unstable
This PR just hardens the tests and improves benchmarks.
More specifically:
1. Benchmarks don't generate vectors in `Bencher::iter` loops, but simply clone pregenerated vectors.
2. Benchmark `*_strings` doesn't allocate Strings in `Bencher::iter` loops, but merely clones a `Vec<&str>`.
3. Benchmarks use seeded `XorShiftRng` to be more consistent.
4. Additional tests for `slice::sort` are added, which test sorting on slices with several ascending/descending runs. The implementation identifies such runs so it's a good idea to test that scenario a bit.
5. More checks are added to `run-pass/vector-sort-panic-safe.rs`. Sort algorithms copy elements around a lot (merge sort uses an auxilliary buffer and pdqsort copies the pivot onto the stack before partitioning, then writes it back into the slice). If elements that are being sorted are internally mutable and comparison function mutates them, it is important to make sure that sort algorithms always use the latest "versions" of elements. New checks verify that this is true for both `slice::sort` and `slice::sort_unstable`.
As a side note, all of those improvements were made as part of the parallel sorts PR in Rayon (nikomatsakis/rayon#379) and now I'm backporting them into libcore/libstd.
r? @alexcrichton
|
|
Coerce fields to the expected field type
Fully fixes #31260.
This needs a crater run. I was supposed to do this last month but it slipped. Let's get this done.
|
|
|
|
|
|
std: Fix implementation of `Alloc::alloc_one`
This had an accidental `u8 as *mut T` where it was intended to have just a
normal pointer-to-pointer cast.
Closes #42827
|
|
syntax: allow negative integer literal expression to be interpolated as pattern
Fixes #42820.
r? @jseyfried
|
|
Move global vars changing tests into run-pass
Should fix race #42795
|
|
add `allow_fail` test attribute
This change allows the user to add an `#[allow_fail]` attribute to
tests that will cause the test to compile & run, but if the test fails
it will not cause the entire test run to fail. The test output will
show the failure, but in yellow instead of red, and also indicate that
it was an allowed failure.
Here is an example of the output: http://imgur.com/a/wt7ga
|
|
rustc_typeck: enforce argument type is sized
closes #42312
r? @nikomatsakis
|
|
avoid translating roots with predicates that do not hold
Finally I got around to doing this.
Fixes #37725.
r? @nikomatsakis
|
|
|
|
1.19 stabilization
r? @alexcrichton
|
|
re-add the call to `super_statement` in EraseRegions
The move gathering code is sensitive to type-equality - that is rather
un-robust and I plan to fix it eventually, but that's a more invasive
change. And we want to fix the visitor anyway.
Fixes #42903.
r? @eddyb
|
|
The move gathering code is sensitive to type-equality - that is rather
un-robust and I plan to fix it eventually, but that's a more invasive
change. And we want to fix the visitor anyway.
Fixes #42903.
|
|
deriv(Hash) for single-variant enum should not hash discriminant
Fixes #39137
|
|
|
