| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #131633 (error on alignments greater than `isize::MAX`)
- #132086 (Tweak E0277 highlighting and "long type" path printing)
- #132220 (Add GUI regression test for doc struct fields margins)
- #132225 (Dynamically link run-make support)
- #132227 (Pass constness with span into lower_poly_trait_ref)
- #132242 (Support `char::is_digit` in const contexts.)
- #132243 (Remove `ObligationCause::span()` method)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `ObligationCause::span()` method
I think it's an incredibly confusing footgun to expose both `obligation_cause.span` and `obligation_cause.span()`. Especially because `ObligationCause::span()` (the method) seems to just be hacking around a single quirk in the way we set up obligation causes for match arms.
First commit removes the need for that hack, with only one diagnostic span changing (but IMO not really getting worse -- I'd argue that it was already confusing).
|
|
Support `char::is_digit` in const contexts.
This PR implements [`feature(const_char_is_digit)` #132241](https://github.com/rust-lang/rust/issues/132241)
|
|
Pass constness with span into lower_poly_trait_ref
Gives us a span to point at for ~const/const on non-const traits.
Split from #132209. r? Nadrieril
|
|
Dynamically link run-make support
Fixes #131810
r? `@jieyouxu`
|
|
r=notriddle
Add GUI regression test for doc struct fields margins
Fixes #131402.
r? `@notriddle`
|
|
Tweak E0277 highlighting and "long type" path printing
Partially address #132013.
|
|
error on alignments greater than `isize::MAX`
Fixes #131122
On zulip someone had a concern that it was legal to create a type with alignment `isize::MAX + 1`, but I do not believe this should be allowed for `repr(align)`, as `repr(align)` also increases the *size* of the type, and that would be larger than the maximum allowed size of objects.
(cc `@workingjubilee` #131276)
|
|
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
|
|
Make clearer that guarantees in ABI compatibility are for Rust only
cc https://github.com/rust-lang/rust/pull/132136#issuecomment-2439737631 -- it looks like we already had a note that I missed in my initial look here, but this goes further to emphasize the guarantees, including uplifting it to the top of the general documentation.
r? `@RalfJung`
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #132043 (Simplify param handling in `resolve_bound_vars`)
- #132214 (Cleanup: Move an impl-Trait check from AST validation to AST lowering)
- #132221 (Clean up some comments on lint implementation)
- #132228 (Revert "ci update freebsd version proposal, freebsd 12 being eol.")
- #132234 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Miri subtree update
r? `@ghost`
|
|
Revert "ci update freebsd version proposal, freebsd 12 being eol."
This reverts commit 1239c81c145d2bfb96f32856f377cd741d5c7256.
Fix GH-132185 revert for now until early next year/FreeBSD 13.3 becomes EOL.
|
|
Clean up some comments on lint implementation
This updates some doc comments that have gotten very out of date. Some of these macros were removed or renamed in #57726 and #104863 and others. Manual emitting of lints was significantly reworked when the `Diagnostic` infrastructure was added.
Rather than try to replicate the high-level documentation, I added pointers to the rustc-dev-guide.
I linkified some types so that if they are renamed/removed without updating the docs, it will break CI.
|
|
Cleanup: Move an impl-Trait check from AST validation to AST lowering
Namely the one that rejects `impl Trait` in qself types and non-final path segments.
There's no good reason to perform this during AST validation.
We have better infrastructure in place in the AST lowerer (`ImplTraitContext`).
This shaves off a lot of code.
We now lower `impl Trait` in bad positions to `{type error}` which allows us to
remove a special case from HIR ty lowering.
Coincidentally fixes #126725. Well, it only *masks* it by passing `{type error}` to HIR analysis instead of a "bad" opaque. I was able to find a new reproducer for it. See the issue.
|
|
Simplify param handling in `resolve_bound_vars`
I always found the flow of the `ResolvedArg` constructors to be a bit confusing; turns out they're also kinda redundantly passing around their data, too.
Also, deduplicate some code handling early-bound var to late-bound var conversion between return type notation's two styles: `where <T as Trait>::method(..): Bound` and `where T: Trait<method(..): Bound>`.
|
|
dingxiangfei2009:rename-smart-ptr-to-coerce-referent, r=compiler-errors
Rename macro `SmartPointer` to `CoercePointee`
As per resolution #129104 we will rename the macro to better reflect the technical specification of the feature and clarify the communication.
- `SmartPointer` is renamed to `CoerceReferent`
- `#[pointee]` attribute is renamed to `#[referent]`
- `#![feature(derive_smart_pointer)]` gate is renamed to `#![feature(derive_coerce_referent)]`.
- Any mention of `SmartPointer` in the file names are renamed accordingly.
r? `@compiler-errors`
cc `@nikomatsakis` `@Darksonn`
|
|
This reverts commit 1239c81c145d2bfb96f32856f377cd741d5c7256.
Fix GH-132185 revert for now until early next year/FreeBSD 13.3
becomes EOL.
|
|
|
|
simplify force-recompile logic for "library"
It’s kind of self-explanatory when looking at it commit by commit.
|
|
|
|
Round negative signed integer towards zero in `iN::midpoint`
This PR changes the implementation of `iN::midpoint` (the signed variants) to round negative signed integers **towards zero** *instead* of negative infinity as is currently the case.
This is done so that the obvious expectations[^1] of `midpoint(a, b) == midpoint(b, a)` and `midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even more obvious implementation `(a + b) / 2` always true.
The unsigned variants `uN::midpoint` (which are being [FCP-ed](https://github.com/rust-lang/rust/pull/131784#issuecomment-2417188117)) already rounds towards zero, so there is no consistency issue.
cc `@scottmcm`
r? `@dtolnay`
[^1]: https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
|
|
|
|
coverage: Don't rely on the custom traversal to find enclosing loops
This opens up the possibility of modifying or removing the custom graph traversal used in coverage counter creation, without losing access to the heuristics that care about a node's enclosing loops.
Actually changing the traversal is left for future work, because this PR on its own doesn't change the emitted coverage mappings at all.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #132123 (allow type-based search on foreign functions)
- #132183 (Fix code HTML items making big blocks if too long)
- #132192 (expand: Stop using artificial `ast::Item` for macros loaded from metadata)
- #132205 (docs: Correctly link riscv32e from platform-support.md)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
It will run at the project root, so resolving absolute/top-level paths
is unnecessary.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
r=tgross35
docs: Correctly link riscv32e from platform-support.md
Correctly link the riscv32e platform support page.
Just a mistake during the iteration of https://github.com/rust-lang/rust/pull/130555 that was missed in review. Presumably the rv32e-none and rv32i-none pages eventually should get merged, but this is a relatively recent addition to the ISA definition so it is not clear the current RISCV Embedded group has the expertise on-hand... nor did it have their consent.
|
|
expand: Stop using artificial `ast::Item` for macros loaded from metadata
You don't need a full `Item` for that, and not using a piece of AST helps with https://github.com/rust-lang/rust/pull/131808.
|
|
Fix code HTML items making big blocks if too long
Encountered this bug randomly where `code` item in docblocks would look like this:
With this fix it looks like this:
r? ``@notriddle``
|
|
allow type-based search on foreign functions
fixes https://github.com/rust-lang/rust/issues/131804
preferably will be merged after #129708, but that may take a while to be approved due to being a new feature, whereas this is definitely a bug, and should be fixed.
|
|
Replace some LLVMRust wrappers with calls to the LLVM C API
This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.
To make this convenient and sound, two pieces of supporting code have also been added:
- A simple proc-macro that derives `TryFrom<u32>` for fieldless enums
- A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about
In a few places, the use of safe wrapper functions means that an `unsafe` block is no longer needed, so the affected code has changed its indentation level.
|
|
rustc_target: Add pauth-lr aarch64 target feature
Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.
r? `@Amanieu`
|
|
|
|
|
|
Add an unstable `const_sockaddr_setters` feature
Unstably add `const` to the `sockaddr_setters` methods. Included API:
```rust
// core::net
impl SocketAddr {
pub const fn set_ip(&mut self, new_ip: IpAddr);
pub const fn set_port(&mut self, new_port: u16);
}
impl SocketAddrV4 {
pub const fn set_ip(&mut self, new_ip: Ipv4Addr);
pub const fn set_port(&mut self, new_port: u16);
}
impl SocketAddrV6 {
pub const fn set_ip(&mut self, new_ip: Ipv6Addr);
pub const fn set_port(&mut self, new_port: u16);
}
```
Tracking issue: <https://github.com/rust-lang/rust/issues/131714>
|
|
|
|
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #131875 (Add WASM | WASI | Emscripten groups to triagebot.toml)
- #132019 (Document `PartialEq` impl for `OnceLock`)
- #132182 (Downgrade `untranslatable_diagnostic` and `diagnostic_outside_of_impl` to `allow`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Instead of towards negative infinity as is currently the case.
This done so that the obvious expectations of
`midpoint(a, b) == midpoint(b, a)` and
`midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even
more obvious implementation `(a + b) / 2` true.
https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
|
|
Downgrade `untranslatable_diagnostic` and `diagnostic_outside_of_impl` to `allow`
Current implementation of translatable diagnostics infrastructure unfortunately causes some friction for compiler contributors. While we don't have a redesign that causes less friction in place, let's downgrade the internal `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints so we don't indicate to contributors that they *have* to use the current translation infra.
I purposefully left `#[allow(untranslatable_diagnostic)]` and `#[allow(diagnostic_outside_of_impl)]` instances untouched because that seems like unnecessary additional churn.
See <https://github.com/rust-lang/rust/issues/132181> for context.
r? `@davidtwco` (or wg-diagnostics/compiler)
|
|
r=Mark-Simulacrum
Document `PartialEq` impl for `OnceLock`
Adds documentation to `std::sync::OnceLock`'s `PartialEq` implementation: specifies publicly that `OnceLock`s are compared based on their contents, and nothing else.
Created in response to, but not directly related to, https://github.com/rust-lang/rust/issues/131959.
## ne
This doesn't create and document `PartialEq::ne`. There's precedent for this in [`RefCell`](https://doc.rust-lang.org/std/cell/struct.RefCell.html#impl-PartialEq-for-RefCell%3CT%3E).
|
