| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Prepare Rust 1.84.0 stable release
Included a backport of https://github.com/rust-lang/rust/issues/135034, and squashed the release notes.
r? `@ghost`
|
|
environment"
This reverts commit 33ac202904e7820268b71b3280a7d2590378e3b9.
|
|
This reverts commit 4454fa998c9da1f1eee1602c8e8cd2732505c104.
|
|
|
|
|
|
When `-Cstrip` was changed to use the bundled rust-objcopy instead of
/usr/bin/strip on OSX, strip-like arguments were preserved.
But strip and objcopy are, while being the same binary, different, they
have different defaults depending on which binary they are.
Notably, strip strips everything by default, and objcopy doesn't strip
anything by default.
Additionally, `-S` actually means `--strip-all`, so debuginfo stripped
everything and symbols didn't strip anything.
We now correctly pass `--strip-debug` and `--strip-all`.
|
|
[beta] backports
- Do not call `extern_crate` on current trait on crate mismatch errors #133585
- Correctly handle comments in attributes in doctests source code #134260
- Correctly document CTFE behavior of is_null and methods that call is_null. #134325
- Make sure we handle `backwards_incompatible_lint` drops appropriately in drop elaboration #134486
- Bump compiler `cc` to 1.2.5 #134505
- Handle `DropKind::ForLint` in coroutines correctly #134575
- docs: inline `std::ffi::c_str` types to `std::ffi` #134791
- docs: inline `alloc::ffi::c_str` types to `alloc::ffi` #134851
r? cuviper
|
|
(cherry picked from commit 11ad6ff3cb3cb3da0040541877c716ddc38ec388)
|
|
(cherry picked from commit fc8a541eaa4b6555d948c382b75677b0e17040fa)
|
|
Rustdoc has no way to show that an item is stable,
but only at a different path. `std::ffi::c_str::NulError` is
not stable, but `std::ffi::NulError` is.
To avoid marking these types as unstable when someone just
wants to follow a link from `CString`, inline them into their
stable paths.
(cherry picked from commit 40b0026a2f1c50e88909f49e8ef8c7ae074f5a9b)
|
|
(cherry picked from commit 42d1a4c48bd2c914f30fc6e97f9a1beda0c97729)
|
|
- `cc` 1.2.4 contains a fix to address [rustc uses wrong build tools
when compiling from MSVC
#133794](https://github.com/rust-lang/rust/issues/133794). See
<https://github.com/rust-lang/cc-rs/releases/tag/cc-v1.2.4>.
- `cc` 1.2.5 contains a fix to also check linking when testing if
certain compiler flags are supported, which fixed an issue that was
causing previous compiler `cc` bumps to fail. See
<https://github.com/rust-lang/cc-rs/releases/tag/cc-v1.2.5>.
Co-authored-by: David Lönnhager <david.l@mullvad.net>
(cherry picked from commit 3775d220af5a666b4239c9fdd1e0184d3df0c7a8)
|
|
(cherry picked from commit 6564403641afde8bf445914ec2996fe7219289ab)
|
|
(cherry picked from commit b5350610608b724a3f152ccd889a78f82860ed69)
|
|
(cherry picked from commit 5e079011eafbb1d5fc779c14c7a29d4a620574f9)
|
|
(cherry picked from commit 2e57394d8004b155c6f74ca4e2a1106dedfcccc4)
|
|
(cherry picked from commit e6efbb210b037b7e921eac6db5ec79d3c241e2b4)
|
|
The "panic in const if CTFE doesn't know the answer" behavior was discussed to be the desired behavior in #74939, and is currently how the function actually behaves.
I intentionally wrote this documentation to allow for the possibility that a panic might not occur even if the pointer is out of bounds, because of #133700 and other potential changes in the future.
(cherry picked from commit 93889172bc6fdb085bccf15e201a7c03d1bdc8e3)
|
|
(cherry picked from commit c367cc3ef5648d5695fdb795cc66edbff88b4ce9)
|
|
(cherry picked from commit 23839853425e8c0c80d0aadb32bf5b4ba1bdf64b)
|
|
(cherry picked from commit 9c4a61ff52a635ef96bd92a2ff1fad4a8bb2ce73)
|
|
(cherry picked from commit de16ed35a326041f619de882dfcead1d02623328)
|
|
(cherry picked from commit 998ff2f0cd2902e86178d35b01ba78fe4633f80b)
|
|
(cherry picked from commit e97e15dea55d61d68732bc030be1a44d8a51a1e9)
|
|
When we encounter an error caused by traits/types of different versions of the same crate, filter out the current crate when collecting spans to add to the context so we don't call `extern_crate` on the `DefId` of the current crate, which is meaningless and ICEs.
Produced output with this filter:
```
error[E0277]: the trait bound `foo::Struct: Trait` is not satisfied
--> y.rs:13:19
|
13 | check_trait::<foo::Struct>();
| ^^^^^^^^^^^ the trait `Trait` is not implemented for `foo::Struct`
|
note: there are multiple different versions of crate `foo` in the dependency graph
--> y.rs:7:1
|
4 | extern crate foo;
| ----------------- one version of crate `foo` is used here, as a direct dependency of the current crate
5 |
6 | pub struct Struct;
| ----------------- this type implements the required trait
7 | pub trait Trait {}
| ^^^^^^^^^^^^^^^ this is the required trait
|
::: x.rs:4:1
|
4 | pub struct Struct;
| ----------------- this type doesn't implement the required trait
5 | pub trait Trait {}
| --------------- this is the found trait
= note: two types coming from two different versions of the same crate are different types even if they look the same
= help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `check_trait`
--> y.rs:10:19
|
10 | fn check_trait<T: Trait>() {}
| ^^^^^ required by this bound in `check_trait`
```
Fix #133563.
(cherry picked from commit 8574f374e2cc27b53c8b81dc4031c59ca3035284)
|
|
[beta] Backport rust-lang/rust-analyzer#18711
rust-lang/rust-analyzer#18711
|
|
|
|
[beta] backports
* Update LLVM to 19.1.5 #133799
r? cuviper
|
|
(cherry picked from commit 605306efeff9b95f137e4f21bbdcf9038da68357)
|
|
[beta] Revert r-a completions breakage
As suggested by `@cuviper` in https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Completion.20IDs/near/484770216
Repeats the revert to `stable` https://github.com/rust-lang/rust/pull/133476 using https://patch-diff.githubusercontent.com/raw/rust-lang/rust/pull/133476.diff
cc `@BoxyUwU` `@workingjubilee`
|
|
[beta] bump stage0
bumps stage0 to stable 1.83.0
|
|
|
|
Repeats the revert to `stable` https://github.com/rust-lang/rust/pull/133476
using https://patch-diff.githubusercontent.com/raw/rust-lang/rust/pull/133476.diff
|
|
[beta] Prepare Rust 1.84.0
r? `@ghost`
|
|
|
|
This reverts commit 2316749ca954030afed6145342808a8c1ae29fac.
|
|
This reverts commit f5577a8174685aca342b9189e625648f25a23a20.
|
|
|
|
|
|
distinguish overflow and unimplemented in Step::steps_between
|
|
Stabilize `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local`
Make `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local` stable (+const).
Newly stable API:
```rust
impl Ipv6Addr {
// Newly stable under `ipv6_is_unique_local`
const fn is_unique_local(&self) -> bool;
// Newly stable under `ipv6_is_unique_local`
const fn is_unicast_link_local(&self) -> bool;
}
```
These stabilise a subset of the following tracking issue:
- #27709
I have looked and could not find any issues with `is_unique_local` and `is_unicast_link_local`. There is a well received comment calling for stabilisation of the latter function.
Both functions are well defined and consistent with implementations in other languages:
- [Go](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/net/netip/netip.go;l=518)
- [Python](https://github.com/python/cpython/blob/e9d1bf353c3ccafc0d9b61b1b3688051bc976604/Lib/ipaddress.py#L2319-L2321)
- [Ruby (unique local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#private-3F-source)
- [Ruby (unicast link local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#link_local-3F-source)
cc implementor `@little-dude`
(I can't find the original PR for `is_unqiue_local`)
r? libs-api
`@rustbot` label +T-libs-api +needs-fcp
|
|
|
|
[AIX] change system dynamic library format
Historically on AIX, almost all dynamic libraries are distributed in `.a` Big Archive Format which can consists of both static and shared objects in the same archive (e.g. `libc++abi.a(libc++abi.so.1)`). During the initial porting process, the dynamic libraries are kept as `.a` to simplify the migration, but semantically having an XCOFF object under the archive extension is wrong. For crate type `cdylib` we want to be able to distribute the libraries as archives as well.
We are migrating to archives with the following format:
```
$ ar -t lib<name>.a
lib<name>.so
```
where each archive contains a single member that is a shared XCOFF object that can be loaded.
|
|
ci: Disable full `debuginfo-level=2` in windows alt job
try-job: dist-x86_64-msvc-alt
|
|
fmt
fix cfg for windows
remove unused imports
address comments
update libc to 0.2.164
fmt
remove unused imports
|
|
Rollup of 6 pull requests
Successful merges:
- #130236 (unstable feature usage metrics)
- #131544 (Make asm label blocks safe context)
- #131586 (Support s390x z13 vector ABI)
- #132489 (Fix closure arg extraction in `extract_callable_info`, generalize it to async closures)
- #133078 (tests: ui/inline-consts: add issue number to a test, rename other tests)
- #133283 (Don't exclude relnotes from `needs-triage` label)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't exclude relnotes from `needs-triage` label
So initially we *didn't* exclude `needs-triage` label, then we did exclude them in #132825 as sometimes the `needs-triage` is redundant. However, I think they are probably worth double-checking because often some of the labels are only accurate/relevant for the *implementation* PR, but not for the purposes of the relnotes tracking issue. Furthermore, sometimes relevant team labels can be removed. So to make it less likely for relnotes to slip through, I think we should still label relnotes-tracking-issues with `needs-triage`.
cc https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Please.20CC.20lang
r? release
|
|
tests: ui/inline-consts: add issue number to a test, rename other tests
rename other tests from a_b_c to a-b-c
|
|
Fix closure arg extraction in `extract_callable_info`, generalize it to async closures
* Fix argument extraction in `extract_callable_info`
* FIx `extract_callable_info` to work for async closures
* Remove redundant `is_fn_ty` which is just a less general `extract_callable_info`
* More precisely name what is being called (i.e. call it a "closure" not a "function")
Review this without whitespace -- I ended up reformatting `extract_callable_info` because some pesky `//` comments were keeping the let-chains from being formatted.
|
|
Support s390x z13 vector ABI
cc #130869
This resolves the following fixmes:
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/abi/call/s390x.rs#L1-L2
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9-L11
Refs: Section 1.2.3 "Parameter Passing" and section 1.2.5 "Return Values" in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1)
This PR extends ~~https://github.com/rust-lang/rust/pull/127731~~ https://github.com/rust-lang/rust/pull/132173 (merged) 's ABI check to handle cases where `vector` target feature is disabled.
If we do not do ABI check, we run into the ABI problems as described in https://github.com/rust-lang/rust/issues/116558 and https://github.com/rust-lang/rust/issues/130869#issuecomment-2408268044, and the problem of the compiler generating strange code (https://github.com/rust-lang/rust/pull/131586#discussion_r1799003554).
cc `@uweigand`
`@rustbot` label +O-SystemZ +A-ABI
|
