| Age | Commit message (Collapse) | Author | Lines |
|
This prepares the tree for the 1.20.0 stable release. The `cargo` submodule is
already updated to the tip of rust-1.20.0 so this just updates the channel we're
built in.
|
|
|
|
|
|
|
|
This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes #42808
|
|
No test cases for these ones, but they would all ICE if they ever run
with a non-empty set of obligations.
|
|
Fixes #43923.
|
|
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
Fixes #43250.
|
|
Historically many `Display` and `Debug` implementations for `OsStr`-like
abstractions have gone through `String::from_utf8_lossy`, but this was updated
in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the
unfortunate side effect of causing a regression (#43765) in code which relied on
these `fmt` trait implementations respecting the various formatting flags
specified.
This commit opportunistically adds back interpretation of formatting trait flags
in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can
delegate to the formatting implementation for `str`. This doesn't entirely solve
the regression as non-utf8 paths will format differently than they did before
still (in that they will not respect formatting flags), but this should solve
the regression for all "real world" use cases of paths and such. The door's also
still open for handling these flags in the future!
Closes #43765
|
|
A change in #41911 had made `for_all_relevant_impls` do a linear scan over
all impls, instead of using an HashMap. Use an HashMap again to avoid
quadratic blowup when there is a large number of structs with impls.
I think this fixes #43141 completely, but I want better measurements in
order to be sure. As a perf patch, please don't roll this up.
|
|
Uplift fix for include! in doc tests to beta
Uplift https://github.com/rust-lang/rust/pull/43782 to beta. Fixes #43153.
r? @alexcrichton
(approved by @rust-lang/dev-tools )
|
|
This reverts commit 9b85e1cfa5aa2aaa4b5df4359a023ad793983ffc, reversing
changes made to 13157c4ebcca735a0842bd03c3dad1de7c429f9f.
|
|
nikomatsakis:incr-comp-anonymize-trait-selection, r=michaelwoerister"
This reverts commit b4502f7c0b51526d0177204a71dc2b3200f7348b, reversing
changes made to 23ecebd6bd4362142ac586014aec44070a177a3d.
|
|
This reverts commit 309ab478d31a699493fdb1593d9cb133705f51f0.
|
|
rather than a dummy name
|
|
|
|
Backporting accepted PRs to beta
Backport of:
* https://github.com/rust-lang/rust/pull/43735
* https://github.com/rust-lang/rust/pull/43546
* https://github.com/rust-lang/rust/pull/43513
* https://github.com/rust-lang/rust/pull/43373
* https://github.com/rust-lang/rust/pull/43315
|
|
|
|
|
|
We already had a cache for file contents, but we read the source-file
before testing the cache, causing obvious slowness, so this just avoids
loading the source-file when the cache already has the contents.
|
|
|
|
Stabilizes
* `<&mut str>::as_bytes_mut`
* `<Box<str>>::into_boxed_bytes`
* `std::str::from_boxed_utf8_unchecked`
* `std::str::from_utf8_mut`
* `std::str::from_utf8_unchecked_mut`
Closes #41119
|
|
Stabilizes:
* `compile_error!` as a macro defined by rustc
Closes #40872
|
|
Stabilizes
* `core::mem::ManuallyDrop`
* `std::mem::ManuallyDrop`
* `ManuallyDrop::new`
* `ManuallyDrop::into_inner`
* `ManuallyDrop::drop`
* `Deref for ManuallyDrop`
* `DerefMut for ManuallyDrop`
Closes #40673
|
|
Stabilizes:
* `Utf8Error::error_len`
Closes #40494
|
|
Stabilizes:
* `CString::as_c_str`
* `CString::into_boxed_c_str`
* `CStr::into_c_string`
* `OsString::into_boxed_os_str`
* `OsStr::into_os_string`
* `PathBuf::into_boxed_path`
* `PathBuf::into_path_buf`
Closes #40380
|
|
Stabilized
* `<str>::get`
* `<str>::get_mut`
* `<str>::get_unchecked`
* `<str>::get_unchecked_mut`
Closes #39932
|
|
Stabilized:
* `Option::get_or_insert`
* `Option::get_or_insert_with`
Closes #39288
|
|
Stabilizes:
* `<char>::escape_debug`
* `std::char::EscapeDebug`
Closes #35068
|
|
This fixes an optimization regression by allowing LLVM to see through more
functions.
Closes #43272
|
|
|
|
@alexcrichton figured out a way how to do it :)
|
|
|
|
This allows building with libressl 2.6
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
No need to bootstrap from dev any more!
|
|
[beta] Prepare the 1.20.0 beta release
This commit prepares the freshly branched `beta` branch to start bootstrapping
from the 1.19.0 preview artifacts as well as build in beta mode.
Closes https://github.com/rust-lang/rust/issues/43200
Closes https://github.com/rust-lang/rust/issues/43218
|
|
|
|
This commit prepares the freshly branched `beta` branch to start bootstrapping
from the 1.19.0 preview artifacts as well as build in beta mode.
|
|
Add support for dylibs with Address Sanitizer
Many applications use address sanitizer to assert correct behaviour of their programs. When using Rust with C, it's much more important to assert correct programs with tools like asan/lsan due to the unsafe nature of the access across an ffi boundary. However, previously only rust bin types could use asan. This posed a challenge for existing C applications that link or dlopen .so when the C application is compiled with asan.
This PR enables asan to be linked to the dylib and cdylib crate type. We alter the test to check the proc-macro crate does not work with -Z sanitizer=address. Finally, we add a test that compiles a shared object in rust, then another rust program links it and demonstrates a crash through the call to the library.
This PR is nearly complete, but I do require advice on the change to fix the -lasan that currently exists in the dylib test. This is required because the link statement is not being added correctly to the rustc build when -Z sanitizer=address is added (and I'm not 100% sure why)
Thanks,
|
|
r=nikomatsakis
Fix `range_covered_by_constructor` for exclusive ranges.
This resolves #43253
|
|
Change some notes into suggestions
r? @petrochenkov since you commented on the same edits in #39458
|
|
The produced paths aren't stable between builds, since
reporting paths inside resolve, before resolve is finished
might produce paths resolved to type aliases instead of
the concrete type.
Compile-fail tests can match just parts of messages, so they
don't "suffer" from this issue.
This is just a workaround, the instability should be fixed
in the future.
|
|
|
|
|
|
More Rust/RLS integration
r? @alexcrichton
cc https://github.com/rust-lang-nursery/rls/issues/310
closes #41199
closes #41197
|
|
|
|
|
|
Compile `compiler_builtins` with `abort` panic strategy
A workaround for https://github.com/rust-lang/rust/issues/43095
In case this causes unexpected consequences, I use a simpler workaround locally:
```diff
--- a/src/bootstrap/bin/rustc.rs
+++ b/src/bootstrap/bin/rustc.rs
@@ -175,7 +175,9 @@ fn main() {
}
if let Ok(s) = env::var("RUSTC_CODEGEN_UNITS") {
- cmd.arg("-C").arg(format!("codegen-units={}", s));
+ if crate_name != "compiler_builtins" {
+ cmd.arg("-C").arg(format!("codegen-units={}", s));
+ }
}
// Emit save-analysis info.
```
r? @alexcrichton
|
|
Stabilize float_bits_conv for Rust 1.21
Stabilizes the `float_bits_conv` lib feature for the 1.20 release of Rust. I've initially implemented the feature in #39271 and later made PR #43025 to output quiet NaNs even on platforms with different encodings, which seems to have been the only unresolved issue of the API.
Due to PR #43025 being only applied to master this stabilisation can't happen for Rust 1.19 through the usual "stabilisation on beta" system that is being done for library APIs.
r? @BurntSushi
closes #40470.
|
|
|