| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Plus a tiny bit of reformatting.
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #126013 (Add `#[warn(unreachable_pub)]` to a bunch of compiler crates)
- #128157 (deduplicate and clarify rules for converting pointers to references)
- #129032 (Document & implement the transmutation modeled by `BikeshedIntrinsicFrom`)
- #129250 (Do not ICE on non-ADT rcvr type when looking for crate version collision)
- #129340 (Remove Duplicate E0381 Label)
- #129560 ([rustdoc] Generate source link on impl associated types)
- #129622 (Remove a couple of unused feature enables)
- #129625 (Rename `ParenthesizedGenericArgs` to `GenericArgsMode`)
- #129626 (Remove `ParamMode::ExplicitNamed`)
Failed merges:
- #128166 (Improved `checked_isqrt` and `isqrt` methods)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `ParamMode::ExplicitNamed`
This was introduced as a hack to improve a diagnostics suggestion in #61679. It was subsequently broken, but also it was an incomplete hack that I don't believe we need to support, so let's just remove it.
|
|
Rename `ParenthesizedGenericArgs` to `GenericArgsMode`
A bit easier to digest name. Broken out of a PR implementing return type notation.
|
|
Remove a couple of unused feature enables
|
|
r=notriddle
[rustdoc] Generate source link on impl associated types
Currently, impl associated types are generated but don't get a source link. This PR fixes that.
Before:
After:
r? `@notriddle`
|
|
r=compiler-errors
Remove Duplicate E0381 Label
Aims to resolve https://github.com/rust-lang/rust/issues/129274, and adds a test for the case.
Essentially, we are duplicating this span for some reason. For now, I'm just using a set to collect the spans rather than the vec. I imagine there's probably no real reason to inspect duplicates in this area, but if I'm wrong I can adjust to collect "seen spans" in just the point where this label is applied.
I'm not sure why it's producing duplicate spans. Looks like this has been this way for a while? I think it gives the duplicate label on 1.75.0 for example.
|
|
Do not ICE on non-ADT rcvr type when looking for crate version collision
When looking for multiple versions of the same crate, do not blindly construct the receiver type.
Follow up to #128786.
Fixes #129205
Fixes #129216
|
|
Document & implement the transmutation modeled by `BikeshedIntrinsicFrom`
Documents that `BikeshedIntrinsicFrom` models transmute-via-union, which is slightly more expressive than the transmute-via-cast implemented by `transmute_copy`. Additionally, we provide an implementation of transmute-via-union as a method on the `BikeshedIntrinsicFrom` trait with additional documentation on the boundary between trait invariants and caller obligations.
Whether or not transmute-via-union is the right kind of transmute to model remains up for discussion [1]. Regardless, it seems wise to document the present behavior.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20'kind'.20of.20transmute.20to.20model.3F/near/426331967
Tracking Issue: https://github.com/rust-lang/rust/issues/99571
r? `@compiler-errors`
cc `@scottmcm,` `@Lokathor`
|
|
deduplicate and clarify rules for converting pointers to references
part of #124669
|
|
Add `#[warn(unreachable_pub)]` to a bunch of compiler crates
By default `unreachable_pub` identifies things that need not be `pub` and tells you to make them `pub(crate)`. But sometimes those things don't need any kind of visibility. So they way I did these was to remove the visibility entirely for each thing the lint identifies, and then add `pub(crate)` back in everywhere the compiler said it was necessary. (Or occasionally `pub(super)` when context suggested that was appropriate.) Tedious, but results in more `pub` removal.
There are plenty more crates to do but this seems like enough for a first PR.
r? `@compiler-errors`
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #129190 (Add f16 and f128 to tests/ui/consts/const-float-bits-conv.rs)
- #129377 (Add implementations for `unbounded_shl`/`unbounded_shr`)
- #129539 (link to Future::poll from the Poll docs)
- #129588 (pal/hermit: correctly round up microseconds in `Thread::sleep`)
- #129592 (Remove cfg(test) from library/core)
- #129597 (mv `build_reduced_graph_for_external_crate_res` into Resolver)
- #129600 (Tie `impl_trait_overcaptures` lint to Rust 2024)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
When looking for multiple versions of the same crate, do not blindly construct the receiver type.
Follow up to #128786. Fix #129205.
|
|
traviscross:TC/tie-impl_trait_overcaptures-to-rust-2024, r=compiler-errors
Tie `impl_trait_overcaptures` lint to Rust 2024
The `impl_trait_overcaptures` lint is part of the migration to Rust 2024 and the Lifetime Capture Rules 2024. Now that we've stabilized precise capturing (RFC 3617), let's tie this lint to the `rust_2024_compatibility` lint group.
Tracking:
- https://github.com/rust-lang/rust/issues/117587
r? `@compiler-errors`
|
|
mv `build_reduced_graph_for_external_crate_res` into Resolver
`build_reduced_graph_for_external_crate_res` is only related to `Resolver`, so move it there.
r? `@petrochenkov`
|
|
Remove cfg(test) from library/core
The diff here is very small with the ignore whitespace option.
`core` doesn't/can't have unit tests. All of its tests are just modules under `tests/`, so it has no use for `cfg(test)`, because the entire contents of `library/core/src` are only ever compiled with that cfg off, and the entire contents of `library/core/tests` are only ever compiled with that cfg on.
You can tell this is what's happening because we had `#[cfg(test)]` on a module declaration that has no source file.
I also deleted the extra `mod tests {` layer of nesting; there's no need to mention again in the module path that this is a module of tests. This exposes a name collision between the `u128` module of tests and `core::u128`. Fixed that by using `<u128>::MAX` like is done in the `check!` macro, which is what avoids this name ambiguity for the other types.
|
|
pal/hermit: correctly round up microseconds in `Thread::sleep`
This fixes the Hermit-related part of https://github.com/rust-lang/rust/issues/129212 and thus the whole issue, since ESP-IDF is already fixed, as far as I understand.
Fixes https://github.com/rust-lang/rust/issues/129212
r? `@workingjubilee`
CC: `@stlankes`
|
|
link to Future::poll from the Poll docs
The most important thing about Poll is that Future::poll returns it, but previously the docs didn't emphasize this.
|
|
Add implementations for `unbounded_shl`/`unbounded_shr`
Tracking Issue: https://github.com/rust-lang/rust/issues/129375
This implements `unbounded_shl` and `unbounded_shr` under the feature gate `unbounded_shifts`
|
|
Add f16 and f128 to tests/ui/consts/const-float-bits-conv.rs
Fixes #129163
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
|
|
const checking: properly compute the set of transient locals
For const-checking the MIR of a const/static initializer, we have to know the set of "transient" locals. The reason for this is that creating a mutable (or interior mutable) reference to a transient local is "safe" in the sense that this reference cannot possibly end up in the final value of the const -- even if it is turned into a raw pointer and stored in a union, we will see that pointer during interning and reliably reject it as dangling.
So far, we determined the set of transient locals as "locals that have a `StorageDead` somewhere". But that's not quite right -- if we had MIR like
```rust
StorageLive(_5);
StorageDead(_5);
StorageLive(_5);
// no further storage annotations for _5
```
Then we'd consider `_5` to be "transient", but it is not actually transient.
We do not currently generate such MIR, but I feel uneasy relying on subtle invariants like this. So this PR implements a proper analysis for computing the set of "transient" locals: a local is "transient" if it is guaranteed dead at all `Return` terminators.
Cc `@cjgillot`
|
|
The `impl_trait_overcaptures` lint is part of the migration to Rust
2024 and the Lifetime Capture Rules 2024. Now that we've stabilized
precise capturing (RFC 3617), let's tie this lint to the
`rust_2024_compatibility` lint group.
|
|
Rollup of 9 pull requests
Successful merges:
- #129288 (Use subtyping for `UnsafeFnPointer` coercion, too)
- #129405 (Fixing span manipulation and indentation of the suggestion introduced by #126187)
- #129518 (gitignore: ignore ICE reports regardless of directory)
- #129519 (Remove redundant flags from `lower_ty_common` that can be inferred from the HIR)
- #129525 (rustdoc: clean up tuple <-> primitive conversion docs)
- #129526 (Use `FxHasher` on new solver unconditionally)
- #129544 (Removes dead code from the compiler)
- #129553 (add back test for stable-const-can-only-call-stable-const)
- #129590 (Avoid taking reference of &TyKind)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Avoid taking reference of &TyKind
It's already a ref anyways. Just a tiny cleanup here.
|
|
add back test for stable-const-can-only-call-stable-const
This got accidentally removed in https://github.com/rust-lang/rust/pull/128596 (file `tests/ui/internal/internal-unstable-const.rs`). The test has little to do with "allow internal unstable" though, so add it in a file that already tests various const stability things.
Also tweak the help that suggests to add `rustc_allow_const_fn_unstable` to make it clear that this needs team approval, since it is a fairly big gun.
|
|
Removes dead code from the compiler
Detected by #128637
|
|
Use `FxHasher` on new solver unconditionally
r? lqd
This should actually fix the inference problem in ad855fe6db641755c528fb5b1cc0308f3a4bf607, since `HashSet::default` was not inferring the hasher when `HashSet` was coming from the stdlib due to the way that defaulted types/inference vars work. You could cherry-pick this on top of your PR alternatively.
|
|
r=GuillaumeGomez
rustdoc: clean up tuple <-> primitive conversion docs
This adds a minor missing feature to `fake_variadic`, so that it can render `impl From<(T,)> for [T; 1]` correctly.
|
|
Remove redundant flags from `lower_ty_common` that can be inferred from the HIR
...and then get rid of `lower_ty_common`.
r? ``@fmease`` or re-roll if you're busy!
|
|
gitignore: ignore ICE reports regardless of directory
Quite often when working on compiler I end up running into ICEs during the standard library compilation.
These ICEs generate reports in `/library/` and not at the root of the repo, so they aren't `gitignore`d.
I finally ended up committing one today, by accident: https://github.com/rust-lang/rust/pull/129487#event-14002067843
|
|
Fixing span manipulation and indentation of the suggestion introduced by #126187
According to comments:
https://github.com/rust-lang/rust/pull/128084#issuecomment-2295254576
https://github.com/rust-lang/rust/pull/126187/files#r1634897691
|
|
Use subtyping for `UnsafeFnPointer` coercion, too
I overlooked this in #129059, which changed MIR typechecking to use subtyping for other fn pointer coercions.
Fixes #129285
|
|
Enable Alignment::new_unchecked precondition check
Similar to what happened with https://github.com/rust-lang/rust/pull/126556, I think this has become palatable since https://github.com/rust-lang/rust/pull/126793.
|
|
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
|
|
|
