| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update `catch_unwind` doc comments for `c_unwind`
Updates `catch_unwind` doc comments to indicate that catching a foreign exception _will no longer_ be UB. Instead, there are two possible behaviors, though it is not specified which one an implementation will choose.
Nominated for t-lang to confirm that they are okay with making such a promise based on t-opsem FCP, or whether they would like to be included in the FCP.
Related: https://github.com/rust-lang/rust/issues/74990, https://github.com/rust-lang/rust/issues/115285, https://github.com/rust-lang/reference/pull/1226
|
|
Implement RFC3137 trim-paths sysroot changes - take 2
This PR is a continuation of https://github.com/rust-lang/rust/pull/118149. Nothing really changed, except for https://github.com/rust-lang/rust/pull/129408 which I was able to trigger locally.
Original description:
> Implement parts of #111540
>
> Right now, backtraces into sysroot always shows /rustc/$hash in diagnostics, e.g.
>
> ```
> thread 'main' panicked at 'hello world', map-panic.rs:2:50
> stack backtrace:
> 0: std::panicking::begin_panic
> at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:616:12
> 1: map_panic::main::{{closure}}
> at ./map-panic.rs:2:50
> 2: core::option::Option<T>::map
> at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:929:29
> 3: map_panic::main
> at ./map-panic.rs:2:30
> 4: core::ops::function::FnOnce::call_once
> at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
> ```
>
> [RFC 3127 said](https://rust-lang.github.io/rfcs/3127-trim-paths.html#changing-handling-of-sysroot-path-in-rustc)
>
> > We want to change this behaviour such that, when rust-src source files can be discovered, the virtual path is discarded and therefore the local path will be embedded, unless there is a --remap-path-prefix that causes this local path to be remapped in the usual way.
>
> This PR implements this behaviour. When `rust-src` is present at compile time, rustc replaces /rustc/$hash with a real path into local rust-src with best effort. To sanitise this, users must explicitly supply `--remap-path-prefix=<path to rust-src>=foo`.
cc `@cbeuw`
Fix #105907
Fix #85463
try-job: dist-x86_64-linux
try-job: x86_64-msvc
try-job: dist-x86_64-msvc
try-job: armhf-gnu
|
|
r=the8472
Improve autovectorization of to_lowercase / to_uppercase functions
Refactor the code in the `convert_while_ascii` helper function to make it more suitable for auto-vectorization and also process the full ascii prefix of the string. The generic case conversion logic will only be invoked starting from the first non-ascii character.
The runtime on a microbenchmark with a small ascii-only input decreases from ~55ns to ~18ns per iteration. The new implementation also reduces the amount of unsafe code and encapsulates all unsafe inside the helper function.
Fixes #123712
|
|
Enable `f16` tests on platforms that were missing conversion symbols
The only requirement for `f16` support, aside from LLVM not crashing and no ABI issues, is that symbols to convert to and from `f32` are available. Since the update to compiler-builtins in https://github.com/rust-lang/rust/pull/125016, we now provide these on all platforms.
This also enables `f16` math since there are no further requirements.
Still excluded are platforms for which LLVM emits infinitely-recursing code.
try-job: arm-android
try-job: test-various
try-job: x86_64-fuchsia
|
|
This is done to cover the path of the test it-self as it may not live
on the same root directory as {{rust-src-base}}, which can be the case
if {{rust-src-base}} is coming from a extracted dist build (cc opt-dist)
|
|
in case the real paths into the libstd/libcore are located inside the
the build directory, maybe because it's coming from an extracted dist
component in the build dir (cc opt-dist)
|
|
Update compiler-builtins to 0.1.130
This includes the following which add `__divtf3` and `__powtf2`, and do some feature cleanup:
- https://github.com/rust-lang/compiler-builtins/pull/622
- https://github.com/rust-lang/compiler-builtins/pull/692
- https://github.com/rust-lang/compiler-builtins/pull/614
- https://github.com/rust-lang/compiler-builtins/pull/694
The `cc` bump [1] was previously included but was reverted due to problems updating.
[1]: https://github.com/rust-lang/compiler-builtins/pull/690
|
|
This includes the following which add `__divtf3` and `__powtf2`, and do
some feature cleanup:
- https://github.com/rust-lang/compiler-builtins/pull/622
- https://github.com/rust-lang/compiler-builtins/pull/692
- https://github.com/rust-lang/compiler-builtins/pull/614
- https://github.com/rust-lang/compiler-builtins/pull/694
The `cc` bump [1] was previously included but was reverted due to
problems updating.
[1]: https://github.com/rust-lang/compiler-builtins/pull/690
|
|
Rollup of 5 pull requests
Successful merges:
- #128778 (atomics: allow atomic and non-atomic reads to race)
- #130918 (simplify LLVM submodule handling)
- #130960 (Only add an automatic SONAME for Rust dylibs)
- #130973 (compiletest: rename "runtest/crash.rs" to "runtest/crashes.rs" to be in line with the test directory)
- #130976 (remove couple redundant clones)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
remove couple redundant clones
|
|
compiletest: rename "runtest/crash.rs" to "runtest/crashes.rs" to be in line with the test directory
r? jieyouxu
|
|
Only add an automatic SONAME for Rust dylibs
#126094 added an automatic relative `SONAME` to all dynamic libraries, but it was really only needed for Rust `--crate-type="dylib"`. In Fedora, it was a surprise to see `SONAME` on `"cdylib"` libraries like Python modules, especially because that generates an undesirable RPM `Provides`. We can instead add a `SONAME` just for Rust dylibs by passing the crate-type argument farther.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2314879
|
|
simplify LLVM submodule handling
Fixes #130906.
|
|
atomics: allow atomic and non-atomic reads to race
We currently define our atomics in terms of C++ `atomic_ref`. That has the unfortunate side-effect of making it UB for an atomic and a non-atomic read to race (concretely, [this code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d1a743774e60923db33def7fe314d754) has UB). There's really no good reason for this, all the academic models of the C++ memory model I am aware of allow this -- C++ just disallows this because of their insistence on an "object model" with typed memory, where `atomic_ref` temporarily creates an "atomic object" that may not be accesses via regular non-atomic operations.
So instead of tying our operations to `atomic_ref`, let us tie them directly to the underlying C++ memory model. I am not sure what is the best way to phrase this, so here's a first attempt.
We also carve out an exception from the "no mixed-size atomic accesses" rule to permit mixed-size atomic reads -- given that we permit mixed-size non-atomic reads, it seems odd that this would be disallowed for atomic reads. However, when an atomic write races with any other atomic operation, they must use the same size.
With this change, it is finally the case that every non-atomic access can be replaced by an atomic access without introducing UB.
Cc `@rust-lang/opsem` `@chorman0773` `@m-ou-se` `@WaffleLapkin` `@Amanieu`
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/483
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #125404 (Fix `read_buf` uses in `std`)
- #130866 (Allow instantiating object trait binder when upcasting)
- #130922 (Reference UNSPECIFIED instead of INADDR_ANY in join_multicast_v4)
- #130924 (Make clashing_extern_declarations considering generic args for ADT field)
- #130939 (rustdoc: update `ProcMacro` docs section on helper attributes)
- #130940 (Revert space-saving operations)
- #130944 (Allow instantiating trait object binder in ptr-to-ptr casts)
- #130953 (Rename a few tests to make tidy happier)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
with the test directory
r? jieyouxu
|
|
- UnsafeCell: mention the term "data race", and reference the data race definition
- atomic: failing RMWs are just reads, reorder and reword docs
|
|
|
|
|
|
|
|
library: Compute `RUST_EXCEPTION_CLASS` from native-endian bytes
This makes it appear correctly in hexdumps on both LE and BE platforms.
|
|
Rename a few tests to make tidy happier
A somewhat random smattering of tests that I have recently looked at, and thus had cause to research and write down the reason for their existence.
|
|
Allow instantiating trait object binder in ptr-to-ptr casts
For unsizing coercions between trait objects with the same principal, we already allow instantiating the for binder. For example, coercing `Box<dyn for<'a> Trait<'a>` to `Box<dyn Trait<'static>>` is allowed.
Since ptr-to-ptr casts will insert an unsizing coercion before the cast if possible, this has the consequence that the following compiles already:
```rust
// This compiles today.
fn cast<'b>(x: *mut dyn for<'a> Trait<'a>) -> *mut dyn Trait<'b> {
// lowered as (roughly)
// tmp: *mut dyn Trait<'?0> = Unsize(x) // requires dyn for<'a> Trait<'a> <: dyn Trait<'?0>
// ret: *mut dyn Trait<'b> = PtrToPtr(tmp) // requires dyn Trait<'?0> == dyn Trait<'b>
x as _
}
```
However, if no unsizing coercion is inserted then this currently fails to compile as one type is more general than the other. This PR will allow this code to compile, too, by changing ptr-to-ptr casts of pointers with vtable metadata to use sutyping instead of type equality.
```rust
// This will compile after this PR.
fn cast<'b>(x: *mut dyn for<'a> Trait<'a>) -> *mut Wrapper<dyn Trait<'b>> {
// lowered as (roughly)
// no Unsize here!
// ret: *mut Wrapper<dyn Trait<'b>> = PtrToPtr(x) // requires dyn for<'a> Trait<'a> == dyn Trait<'b>
x as _
}
```
Note that it is already possible to work around the current restrictions and make the code compile before this PR by splitting the cast in two, so this shouldn't allow a new class of programs to compile:
```rust
// Workaround that compiles today.
fn cast<'b>(x: *mut dyn for<'a> Trait<'a>) -> *mut Wrapper<dyn Trait<'b>> {
x as *mut dyn Trait<'_> as _
}
```
r? `@compiler-errors`
cc `@WaffleLapkin`
|
|
r=Kobzol
Revert space-saving operations
The "all of our artifacts" `mv` seems like it may save enough space to matter sometimes, since it can range up to a gigabyte of difference, if memory serves. For the rest, I think we're good.
try-job: dist-aarch64-apple
|
|
rustdoc: update `ProcMacro` docs section on helper attributes
I believe the mention of attribute macros in the section on proc macro helper attributes is erroneous. As far as I can tell, attribute macros cannot define helper attributes.
The following attribute macro is not valid (fails to build), no matter how I try to define (or skip defining) the helpers:
```rust
#[proc_macro_attribute(attributes(helper))]
pub fn attribute_helpers(_attr: TokenStream, item: TokenStream) -> TokenStream {
item
}
```
The [language reference](https://doc.rust-lang.org/reference/procedural-macros.html#attribute-macros) also doesn't seem to mention attribute macro helpers. The helpers subsection is inside the section on derive macros.
|
|
Make clashing_extern_declarations considering generic args for ADT field
In following example, G<u16> should be recognized as different from G<u32> :
```rust
#[repr(C)] pub struct G<T> { g: [T; 4] }
pub mod x { extern "C" { pub fn g(_: super::G<u16>); } }
pub mod y { extern "C" { pub fn g(_: super::G<u32>); } }
```
fixes #130851
|
|
Reference UNSPECIFIED instead of INADDR_ANY in join_multicast_v4
|
|
Allow instantiating object trait binder when upcasting
This PR fixes two bugs (that probably need an FCP).
### We use equality rather than subtyping for upcasting dyn conversions
This code should be valid:
```rust
#![feature(trait_upcasting)]
trait Foo: for<'h> Bar<'h> {}
trait Bar<'a> {}
fn foo(x: &dyn Foo) {
let y: &dyn Bar<'static> = x;
}
```
But instead:
```
error[E0308]: mismatched types
--> src/lib.rs:7:32
|
7 | let y: &dyn Bar<'static> = x;
| ^ one type is more general than the other
|
= note: expected existential trait ref `for<'h> Bar<'h>`
found existential trait ref `Bar<'_>`
```
And so should this:
```rust
#![feature(trait_upcasting)]
fn foo(x: &dyn for<'h> Fn(&'h ())) {
let y: &dyn FnOnce(&'static ()) = x;
}
```
But instead:
```
error[E0308]: mismatched types
--> src/lib.rs:4:39
|
4 | let y: &dyn FnOnce(&'static ()) = x;
| ^ one type is more general than the other
|
= note: expected existential trait ref `for<'h> FnOnce<(&'h (),)>`
found existential trait ref `FnOnce<(&(),)>`
```
Specifically, both of these fail because we use *equality* when comparing the supertrait to the *target* of the unsize goal. For the first example, since our supertrait is `for<'h> Bar<'h>` but our target is `Bar<'static>`, there's a higher-ranked type mismatch even though we *should* be able to instantiate that supertrait binder when upcasting. Similarly for the second example.
### New solver uses equality rather than subtyping for no-op (i.e. non-upcasting) dyn conversions
This code should be valid in the new solver, like it is with the old solver:
```rust
// -Znext-solver
fn foo<'a>(x: &mut for<'h> dyn Fn(&'h ())) {
let _: &mut dyn Fn(&'a ()) = x;
}
```
But instead:
```
error: lifetime may not live long enough
--> <source>:2:11
|
1 | fn foo<'a>(x: &mut dyn for<'h> Fn(&'h ())) {
| -- lifetime `'a` defined here
2 | let _: &mut dyn Fn(&'a ()) = x;
| ^^^^^^^^^^^^^^^^^^^ type annotation requires that `'a` must outlive `'static`
|
= note: requirement occurs because of a mutable reference to `dyn Fn(&())`
```
Specifically, this fails because we try to coerce `&mut dyn for<'h> Fn(&'h ())` to `&mut dyn Fn(&'a ())`, which registers an `dyn for<'h> Fn(&'h ()): dyn Fn(&'a ())` goal. This fails because the new solver uses *equating* rather than *subtyping* in `Unsize` goals.
This is *mostly* not a problem... You may wonder why the same code passes on the new solver for immutable references:
```
// -Znext-solver
fn foo<'a>(x: &dyn Fn(&())) {
let _: &dyn Fn(&'a ()) = x; // works
}
```
That's because in this case, we first try to coerce via `Unsize`, but due to the leak check the goal fails. Then, later in coercion, we fall back to a simple subtyping operation, which *does* work.
Since `&T` is covariant over `T`, but `&mut T` is invariant, that's where the discrepancy between these two examples crops up.
---
r? lcnr or reassign :D
|
|
Fix `read_buf` uses in `std`
Following lib-team decision here: https://github.com/rust-lang/rust/issues/78485#issuecomment-2122992314
Guard against the pathological behavior of both returning an error and performing a read.
|
|
bump few deps
Bumps cargo_metadata, thorin-dwp, windows.
Should dedupe some crates around.
|
|
GCC backend subtree update
We just finished the [last sync](https://github.com/rust-lang/rustc_codegen_gcc/pull/556) so time to sync back.
cc `@antoyo`
|
|
Update cargo
19 commits in eaee77dc1584be45949b75e4c4c9a841605e3a4b..80d82ca22abbee5fb7b51fa1abeb1ae34e99e88a
2024-09-19 21:10:23 +0000 to 2024-09-27 17:56:01 +0000
- Update cc to 1.1.22 (rust-lang/cargo#14607)
- feat: lockfile path implies --locked on cargo install (rust-lang/cargo#14556)
- feat(toml): Add `autolib` (rust-lang/cargo#14591)
- fix: correct error count for `cargo check --message-format json` (rust-lang/cargo#14598)
- test: relax panic output assertion (rust-lang/cargo#14602)
- feat(timings): support dark color scheme in HTML output (rust-lang/cargo#14588)
- feat: add CARGO_MANIFEST_PATH env variable (rust-lang/cargo#14404)
- fix(config): Don't double-warn about `$CARGO_HOME/config` (rust-lang/cargo#14579)
- fix(cargo-rustc): give trailing flags higher precedence on nightly (rust-lang/cargo#14587)
- feat: make lockfile v4 the default (rust-lang/cargo#14595)
- perf: Improve quality of completion performance traces (rust-lang/cargo#14592)
- test: Remove completion tests (rust-lang/cargo#14590)
- feat: Add support for completing `cargo update <TAB>` (rust-lang/cargo#14552)
- test: Migrate remaining with_stdout/with_stderr calls (rust-lang/cargo#14577)
- fix(resolve): Improve multi-MSRV workspaces (rust-lang/cargo#14569)
- chore: Bump MSRV to 1.81 (rust-lang/cargo#14585)
- Add a `--dry-run` flag to the `install` command (rust-lang/cargo#14280)
- fix(resolve): Don't list transitive, incompatible dependencies as available (rust-lang/cargo#14568)
- feat(complete): Upgrade clap_complete (rust-lang/cargo#14573)
|
|
|
|
The only requirement for `f16` support, aside from LLVM not crashing and
no ABI issues, is that symbols to convert to and from `f32` are
available. Since the update to compiler-builtins in [1], we now provide
these on all platforms.
This also enables `f16` math since there are no further requirements.
Still excluded are platforms for which LLVM emits infinitely-recursing
code.
[1]: https://github.com/rust-lang/rust/pull/125016
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #130718 (Cleanup some known-bug issues)
- #130730 (Reorganize Test Headers)
- #130826 (Compiler: Rename "object safe" to "dyn compatible")
- #130915 (fix typo in triagebot.toml)
- #130926 (Update cc to 1.1.22 in library/)
- #130932 (etc: Add sample rust-analyzer configs for eglot & helix)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
etc: Add sample rust-analyzer configs for eglot & helix
LSP configuration in editors like Emacs (eglot) and helix does not
use the same JSON format as vscode and vim do. It is not obvious
how to set up LSP for rustc in those editors and the dev guide currently
does not cover them. Adding sample configuration files for those editors
alongside the currently existing JSON one would be helpful.
I figured having those included in the repo like the JSON one might save
someone some time and frustration otherwise spent on trying to get the
more niche editors' LSP to work properly. I'll add a section in the dev
guide too.
|
|
Update cc to 1.1.22 in library/
r? `@ghost`
try-job: x86_64-msvc
|
|
fix typo in triagebot.toml
This pull request fixes a minor typo in the triagebot config file.
|
|
r=compiler-errors
Compiler: Rename "object safe" to "dyn compatible"
Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118.
Tracking issue: https://github.com/rust-lang/rust/issues/130852
Excludes `compiler/rustc_codegen_cranelift` (to be filed separately).
Includes Stable MIR.
Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language).
r? ghost
|
|
Reorganize Test Headers
This PR moves the test headers to the top in a couple of test files to maintain consistent style.
Based on this comment: https://github.com/rust-lang/rust/pull/130665#discussion_r1770506261
|
