| Age | Commit message (Collapse) | Author | Lines |
|---|
|
some improvements to "Invariants of the type system"
|
|
|
|
|
|
trait_sel: `MetaSized` always holds temporarily
As a temporary measure while a proper fix for `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs` is implemented, make `MetaSized` obligations always hold. In effect, temporarily reverting the `sized_hierarchy` feature. This is a small change that can be backported.
cc rust-lang/rust#143992
r? ```@lcnr```
|
|
Update poison.rs
Typo in word "below" previously "bellow"
|
|
Fix handling of SCRIPT_ARG in docker images
Instead of making this a build parameter, pass the SCRIPT as an environment variable.
To this purpose, normalize on always referring to a script in `/scripts`.
For i686-gnu-nopt-2 I had to create a separate script, because Docker seems to be really terrible at command line argument parsing, so it's not possible to pass an environment variable that contains whitespace.
Fixes https://github.com/rust-lang/rust/issues/143962.
try-job: `dist-x86_64-linux`
try-job: `i686-gnu-nopt-*`
try-job: `i686-gnu-*`
try-job: `x86_64-gnu-llvm-19-*`
try-job: `x86_64-gnu-llvm-20-*`
|
|
Improve path segment joining
Currently paths are joined with `::` in many places, in a variety of ways. This PR unifies things.
r? ``@petrochenkov``
|
|
Improve path segment joining
Currently paths are joined with `::` in many places, in a variety of ways. This PR unifies things.
r? ``@petrochenkov``
|
|
r=oli-obk
Dont collect assoc ty item bounds from trait where clause for host effect predicates
For background, we uplift `where Self::Assoc: Trait` bounds in a trait's where clauses into *item bounds* on `type Assoc;`. This is because before we *had* syntactical item bounds, users would express their item bounds like so.
Let's opt out of doing this same behavior for `HostEffect` predicates like `where Self::Assoc: [const] Trait`. I left a comment in the code:
```rust
// FIXME(const_trait_impl): We *could* uplift the
// `where Self::Assoc: [const] Trait` bounds from the parent trait
// here too, but we'd need to split `const_conditions` into two
// queries (like we do for `trait_explicit_predicates_and_bounds`)
// since we need to also filter the predicates *out* of the const
// conditions or they lead to cycles in the trait solver when
// utilizing these bounds. For now, let's do nothing.
```
As an aside, this was an ICE that was only triggerable when building libraries and not binaries because we never were calling `tcx.ensure_ok().explicit_implied_const_bounds(def_id);` on associated types like we should have been. I adjusted the calls to `ensure_ok` to make sure this happens, so we catch bugs like this in the future more easily.
As another aside, I fixed the bound uplifting logic for *always const* predicates, since those act like normal clauses and have no notion of conditional constness.
r? ```@oli-obk``` ```@fee1-dead``` or anyone really
Fixes rust-lang/rust#133275
|
|
Linting public reexport of private dependencies
Part of public/private dependencies rust-lang/rust#44663
Partially addresses rust-lang/rust#71043
I'm adding a warning for reexports of private dependencies into `rustc_resolve`. I get that this should not be a warning, but should instead be a lint to be controlled by the feature gate, but I did not figure out how exactly to do that at that point. I tried doing the same thing as is done in `rustc_privacy`, but the linting system is not ready yet as far as I understand the error I got, so I made a warning for now instead. Some guidance on how to emit lints with `dcx` would be appreciated.
This also sets the `std_detect` crate as a public dependency of `std` because some macros are reexported from there. I did not check closer, but the other option may be to allow the specific reexports instead.
|
|
ci cleanup: rustdoc-gui-test now installs browser-ui-test
this removes the need for --unsafe-perm in the Dockerfile.
cc ```@GuillaumeGomez``` ```@Kobzol```
|
|
Trim `BorrowedCursor` API
This PR removes some method from the unstable `BorrowedCursor` type. A rational for each change can be found in the message of each commit.
I don't think that an ACP is required for this, please tell me if it is not the case.
Cc rust-lang/rust#78485 rust-lang/rust#117693
|
|
Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets
This fixes rust-lang/rust#143804.
|
|
Added error for invalid char cast
fixes rust-lang/rust#143597
not really sure if I did it right, but according to cast-char test -- it is right, also this code gave me false positive result
```
for _ in 0..(256 as u8) {}
```
so this is why I added this check `if lit_val <= 0xFF`
Also I believe that error message could be improved, but I'm not sure how exactly
cc ```@hkBst```
r? compiler
|
|
r=RalfJung,fee1-dead
add `const_make_global`; err for `const_allocate` ptrs if didn't call
Implements as discussed on Zulip: [#t-compiler/const-eval > const heap](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const.20heap/with/527125421)
r? ```@rust-lang/wg-const-eval```
Fixes https://github.com/rust-lang/rust/issues/129233
|
|
UWP: link ntdll functions using raw-dylib
Lazy loading isn't necessary so there's no need for the added complexity and overhead. However, it may be that people using UWP rust libraries don't have the necessary import libraries linked by Visual Studio so this uses raw-dylib, which allows linking to DLL functions without having an import library. This is a somewhat temporary situation as raw-dylib is intended to eventually be the default for all imports. When that happens, this special case can be removed.
Closes rust-lang/rust#143530
|
|
Enable xgot feature for mips64 musl targets
This was missed in b65c2afdfd9aaee977302516c9ef177861abfe74, which only enabled it for the glibc targets.
I didn't feel comfortable touching the OpenWRT target, whoever maintains that will probably want to take a look whether it is necessary there as well.
|
|
Various refactors to the LTO handling code
In particular reducing the sharing of code paths between fat and thin-LTO and making the fat LTO implementation more self-contained. This also moves some autodiff handling out of cg_ssa into cg_llvm given that Enzyme only works with LLVM anyway and an implementation for another backend may do things entirely differently. This will also make it a bit easier to split LTO handling out of the coordinator thread main loop into a separate loop, which should reduce the complexity of the coordinator thread.
|
|
Various refactors to the LTO handling code
In particular reducing the sharing of code paths between fat and thin-LTO and making the fat LTO implementation more self-contained. This also moves some autodiff handling out of cg_ssa into cg_llvm given that Enzyme only works with LLVM anyway and an implementation for another backend may do things entirely differently. This will also make it a bit easier to split LTO handling out of the coordinator thread main loop into a separate loop, which should reduce the complexity of the coordinator thread.
|
|
tests: Add `RUST_BACKTRACE` and `-Cpanic` revisions to `panic-main.rs` test
This is a regression test for rust-lang/rust#123733 (**P-high** and **regression-from-stable-to-stable**) which was [fixed by accident without a regression test](https://github.com/rust-lang/rust/issues/123733#issuecomment-2929091266).
Edit 2025-06-23:
Closes https://github.com/rust-lang/rust/issues/123733
|
|
Implement unstable trait impl
This PR allows marking impls of stable trait with stable type as unstable.
## Approach
In std/core, an impl can be marked as unstable by annotating it with ``#[unstable_feature_bound(feat_name)]``. This will add a ``ClauseKind::Unstable_Feature(feat_name)`` to the list of predicates in ``predicates_of`` .
When an unstable impl's function is called, we will first iterate through all the goals in ``param_env`` to check if there is any ``ClauseKind::UnstableFeature(feat_name)`` in ``param_env``.
The existence of ``ClauseKind::Unstable_Feature(feat_name)`` in ``param_env`` means an``#[unstable_feature_bound(feat_name)]`` is present at the call site of the function, so we allow the check to succeed in this case.
If ``ClauseKind::UnstableFeature(feat_name)`` does not exist in ``param_env``, we will still allow the check to succeed for either of the cases below:
1. The feature is enabled through ``#[feature(feat_name)]`` outside of std / core.
2. We are in codegen because we may be monomorphizing a body from an upstream crate which had an unstable feature enabled that the downstream crate do not.
For the rest of the case, it will fail with ambiguity.
## Limitation
In this PR, we do not support:
1. using items that need ``#[unstable_feature_bound]`` within stable APIs
2. annotate main function with ``#[unstable_feature_bound]``
3. annotate ``#[unstable_feature_bound]`` on items other than free function and impl
## Acknowledgement
The design and mentoring are done by `@BoxyUwU`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This one is a bit marginal, because the segments are a mix of symbols
and strings.
|
|
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
|
|
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
and use it for naked functions
|
|
And more broadly only codegen `InstanceKind::Item` using the naked
function codegen code. Other instance kinds should follow the normal
path.
|
|
go over invariants again :3
|
|
Co-authored-by: Boxy <rust@boxyuwu.dev>
|
|
More details: 1. Moved the return type of IntrinsicType::from_c to
Rust<Self, String> from Result<Box<Self>, String>
|
|
Add tailexpr & -> &mut for generate_mut_trait_impl
|
|
Closes rust-lang/rust-clippy#15283
----
changelog: [`ptr_as_ptr`]: fix wrong suggestions with turbo fish
|
|
|
|
This PR supersedes #14328 following the [2025-03-18 Clippy meeting
discussion](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/Meeting.202025-03-18/with/506527762).
It uses a simpler approach than what was proposed initially in #14328
and does not add new options.
First, it documents how `cfg_attr` can be used to change the MSRV
considered by Clippy to trigger the lint. This allows the MSRV to be
feature gated, or to be raised in tests.
Also, the lint stops warning about items which have been explicitly
allowed through a rustc feature. This works even if the feature has been
stabilized since. It allows using an older compiler with some features
turned on, as is done in Rust for Linux. This fixes #14425.
Then, if the lint triggers, and it looks like the code is located below
a `cfg` or `cfg_attr` attribute, an additional note is issued, once, to
indicate that the `clippy::msrv` attribute can be controlled by an
attribute.
Finally, the lint is extended to cover any path, not just method and
function calls. For example, enumeration variants, or constants, were
not MSRV checked. This required replacing two `u32::MAX` by
`u32::max_value()` in MSRV-limited tests.
An extra commit adds a TODO for checking the const stability also, as
this is not done right now.
@Centri3 I'll assign this to you because you were assigned #14328 and
you were the one who nominated the issue for discussion (thanks!), but
of course feel free to reroll!
r? @Centri3
changelog: [`incompatible_msrv`]: better documentation, honor the
`features` attribute, and lint non-function entities as well
|
|
To avoid false positives, the `range_plus_one` and `range_minus_one`
lints will restrict themselves to situations where the iterator types
can be easily switched from exclusive to inclusive or vice-versa. This
includes situations where the range is used as an iterator, or is used
for indexing.
On the other hand, assignments of the range to variables, including
automatically typed ones or wildcards, will no longer trigger the lint.
However, the cases where such an assignment would benefit from the lint
are probably rare.
In a second commit, the `range_plus_one` and `range_minus_one` logic are
unified, in order to properly emit parentheses around the suggestion
when needed.
Fix rust-lang/rust-clippy#3307
Fix rust-lang/rust-clippy#9908
changelog: [`range_plus_one`, `range_minus_one`]: restrict lint to cases
where it is safe to switch the range type
*Edit:* as a consequence, this led to the removal of three
`#[expect(clippy::range_plus_one)]` in the Clippy sources to avoid those
false positives.
|
|
Fixes https://github.com/rust-lang/rust-clippy/issues/15151
See also
https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/uninlined_format_args.20is.20contentious/
changelog: Move [`uninlined_format_args`] to `pedantic`
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Add AsRef and Borrow for generate_mut_trait_impl
|
|
No longer suggests `&[i32]` or `&mut [i32]` instead of `&Vec<i32>` or
`&mut Vec<i32>` (also: `Path` and `PathBuf`, etc.) for the parameter
type when the parameter name starts with an underscore (or, if that does
not start with one, then a local `let` binding in the function body,
pointing to the same value, does) – (Fixes rust-lang/rust-clippy#13489,
fixes rust-lang/rust-clippy#13728)
~changelog: fix false positive: [`ptr_arg`] no longer triggers with
underscore binding to `&mut` argument~
changelog: fix false positive: [`ptr_arg`] no longer triggers with
underscore binding to `&T` or `&mut T` argument
*Edit:* This change has been extended to all references, not just
mutable ones. See [discussion below](#issuecomment-3006386877).
|
|
Add AsMut to minicore prelude::v1
|
