| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
The optimized clone method ends up as the following MIR:
```
_2 = copy ((*_1).0: i32);
_3 = copy ((*_1).1: u64);
_4 = copy ((*_1).2: [i8; 3]);
_0 = Foo { a: move _2, b: move _3, c: move _4 };
```
We can transform this to:
```
_0 = copy (*_1);
```
|
|
[bootstrap] Add support for building gcc and libgccjit
As `@eholk` summarized below:
> From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use.
It'll greatly improve the experience for anyone wanting to work on the GCC backend from the compiler.
Should help with https://github.com/rust-lang/rust/issues/124172.
Will unblock #124353.
r? `@Kobzol`
|
|
r=albertlarsan68
bootstrap: handle worktrees in warn_old_master_branch
fixes #130111
|
|
Rollup of 6 pull requests
Successful merges:
- #129320 (Fix crash when labeling arguments for call_once and friends)
- #130266 (target: default to the medium code model on LoongArch targets)
- #130297 (Dataflow cleanups)
- #130299 (Add set_dcx to ParseSess)
- #130301 (some fixes for clashing_extern_declarations lint)
- #130305 (Clippy: consider msrv for const context for const_float_bits_conv)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=flip1995
Clippy: consider msrv for const context for const_float_bits_conv
When `const_float_bits_conv` was stabilized for 1.83.0, clippy lints started to be triggered in const context ignoring MSRV. This PR makes the lints trigger in const context only when the MSRV meets 1.83.0.
Fixes https://github.com/rust-lang/rust-clippy/issues/13383.
|
|
r=compiler-errors
some fixes for clashing_extern_declarations lint
There were two issues with the clashing_extern_declarations lint:
- It would accept non-`repr(C)` structs as compatible with each other by comparing their fields in declaration order, but the fields could have different memory order (and with `-Zrandomize-layout`, this can really happen).
- It would accept two types as compatible if `compare_layouts` returns `true`, but that function actually just compared the *ABI*, not the fully layout -- and all sized structs with more than 2 fields have the same ABI (`Abi::Aggregate`), so this missed a *lot* of cases.
We don't currently have a clear spec for what we *want* to consider "clashing" and what is fine, so I otherwise kept the original logic. I hope to have a t-lang discussion about this at some point. But meanwhile, these changes seem like clear bugfixes.
|
|
Add set_dcx to ParseSess
After [this](https://github.com/rust-lang/rust/pull/126623) PR was merged, it is no longer possible to inject one's own `Emitter` in the way [described in the Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/rustc-driver-getting-diagnostics.html). The reason is that the `dcx` field in `ParseSess` is no longer public, so it is not possible to update the `dcx` field with a `DiagCtxt` that contains one's own `Emitter` in the `psess_created` callback in `rustc_interface::Config`. The only way I have found to insert my own `DiagCtxt` is by creating an entirely new `ParseSess` and replacing the old one. This is not a good solution as the original `ParseSess` contains fields I would like to keep. (In my case the problem is that I lose the `cfg` and `check-cfg` fields of the original.)
The solution proposed in this PR is to add a `set_dcx` method to `ParseSess`. Per my limited understanding of the rustc codebase this should be fine as `set_dcx` requires a mutable reference to `ParseSess`, which is as far as I know only available in the `psess_created` callback (outside of `rustc_interface::run_compiler`).
If this PR is accepted, I will create a new PR to update the aforementioned example in the Compiler Development Guide.
|
|
Dataflow cleanups
r? `@cjgillot`
|
|
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
Relands [2]: #120661
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
[2]: https://github.com/rust-lang/rust/issues/121289#issuecomment-2333687396
|
|
Fix crash when labeling arguments for call_once and friends
When calling a method on Fn* traits explicitly, argument diagnostics should point at the called method (eg Fn::call_once), not the underlying callee.
This PR makes 3 main changes:
* It uses TupleArguments to detect if the user called a Fn* method directly (`my_fn.call_once(…)`) or implicitly (`my_fn(…)`). If it was explicit, argument diagnostics should point at the call_once method, not the underlying callable.
* The previous state was causing confusion between the two arguments lists (which could be different lengths), causing an out-of-bounds slice indexing in #128848. I added a length assert to capture the requirement in case this regresses or happens in another case.
* Unfortunately, this assert tripped when the required arguments information was not available (`self.get_hir_params_with_generics` was returning an empty Vec), so I've updated that to return None when that information is not available. (cc `@strottos` if you have any comments, since you added this function in #121595) Sorry this causes a bunch of indentation changes, recommend reviewing [ignoring whitespace](https://github.com/rust-lang/rust/pull/129320/files?w=1).)
This is my first rustc PR, so please call out if you'd like this split into more commits (or PRs), style nits, etc. I will add a few comments/questions inline. Thank you!
Fixes #128848
|
|
|
|
interpret: simplify SIMD type handling
This is possible as a follow-up to https://github.com/rust-lang/rust/pull/129403
|
|
point at the called method (eg Fn::call_once), not the underlying callee.
Fixes 128848
|
|
|
|
|
|
This reverts the part of commit 19908ff7a37a9a431399bb6f2868efc22820f2b6 in
subdirectory src/tools/clippy/clippy_lints.
|
|
Rollup of 3 pull requests
Successful merges:
- #130245 (make basic allocation functions track_caller in Miri for nicer backtraces)
- #130261 (skip target sanity check when it's a `local-rebuild`)
- #130287 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 9))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 9)
Follow up
* https://github.com/rust-lang/rust/pull/116214
* https://github.com/rust-lang/rust/pull/116432
* https://github.com/rust-lang/rust/pull/116824
* https://github.com/rust-lang/rust/pull/118105
* https://github.com/rust-lang/rust/pull/119561
* https://github.com/rust-lang/rust/pull/123574
* https://github.com/rust-lang/rust/pull/125382
* https://github.com/rust-lang/rust/pull/127671
As always, it's easier to review the commits one at a time. Don't use the Files Changed tab. It's confusing.
|
|
skip target sanity check when it's a `local-rebuild`
Running the stage0 target sanity check on the newly built compiler can result in errors and incorrect assumptions.
Resolves #130242
|
|
make basic allocation functions track_caller in Miri for nicer backtraces
This matches what we did with basic pointer and atomic operations.
|
|
|
|
r=michaelwoerister
Don't leave debug locations for constants sitting on the builder indefinitely
Because constants are currently emitted *before* the prologue, leaving the debug location on the IRBuilder spills onto other instructions in the prologue and messes up both line numbers as well as the point LLVM chooses to be the prologue end.
Example LLVM IR (irrelevant IR elided):
Before:
```
define internal { i64, i64 } `@_ZN3tmp3Foo18var_return_opt_try17he02116165b0fc08cE(ptr` align 8 %self) !dbg !347 { start:
%self.dbg.spill = alloca [8 x i8], align 8
%_0 = alloca [16 x i8], align 8
%residual.dbg.spill = alloca [0 x i8], align 1
#dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
store ptr %self, ptr %self.dbg.spill, align 8, !dbg !357
#dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)
```
After:
```
define internal { i64, i64 } `@_ZN3tmp3Foo18var_return_opt_try17h00b17d08874ddd90E(ptr` align 8 %self) !dbg !347 { start:
%self.dbg.spill = alloca [8 x i8], align 8
%_0 = alloca [16 x i8], align 8
%residual.dbg.spill = alloca [0 x i8], align 1
#dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
store ptr %self, ptr %self.dbg.spill, align 8
#dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)
```
Note in particular how !357 from %residual.dbg.spill's dbg_declare no longer falls through onto the store to %self.dbg.spill. This fixes argument values at entry when the constant is a ZST (e.g. `<Option as Try>::Residual`). This fixes #130003 (but note that it does *not* fix issues with argument values and non-ZST constants, which emit their own stores that have debug info on them, like #128945).
r? `@michaelwoerister`
|
|
Revert #130040 - unify llvm-bitcode-linker, wasm-component-ld and llvm-tools logics
This is a revert of #130040 to fix #130291 which is preventing installing nightly with the llvm-tools component due to a conflict with the `bin/llc` file which exists in both the rustc and llvm-tools components.
|
|
Because that's what it is; no point having a different name for it.
|
|
Rescope temp lifetime in if-let into IfElse with migration lint
Tracking issue #124085
This PR shortens the temporary lifetime to cover only the pattern matching and consequent branch of a `if let`.
At the expression location, means that the lifetime is shortened from previously the deepest enclosing block or statement in Edition 2021. This warrants an Edition change.
Coming with the Edition change, this patch also implements an edition lint to warn about the change and a safe rewrite suggestion to preserve the 2021 semantics in most cases.
Related to #103108.
Related crater runs: https://github.com/rust-lang/rust/pull/129466.
|
|
This reverts commit adaff5368b0c7b328a0320a218751d65ab1bba97, reversing
changes made to 2e8db5e9e39c2bf7729113b3041ef4011d90ac5a.
|
|
Fix anon const def-creation when macros are involved
Fixes #128016.
Ever since #125915, some `ast::AnonConst`s turn into `hir::ConstArgKind::Path`s,
which don't have associated `DefId`s. To deal with the fact that we don't have
resolution information in `DefCollector`, we decided to implement a process
where if the anon const *appeared* to be trivial (i.e., `N` or `{ N }`), we
would avoid creating a def for it in `DefCollector`. If later, in AST lowering,
we realized it turned out to be a unit struct literal, or we were lowering it
to something that didn't use `hir::ConstArg`, we'd create its def there.
However, let's say we have a macro `m!()` that expands to a reference to a free
constant `FOO`. If we use `m!()` in the body of an anon const (e.g., `Foo<{ m!() }>`),
then in def collection, it appears to be a nontrivial anon const and we create
a def. But the macro expands to something that looks like a trivial const arg,
but is not, so in AST lowering we "fix" the mistake we assumed def collection
made and create a def for it. This causes a duplicate definition ICE.
The long-term fix for this is to delay the creation of defs for all expression-like
nodes until AST lowering (see #128844 for an incomplete attempt at this). This
would avoid issues like this one that are caused by hacky workarounds. However,
doing this uncovers a pre-existing bug with opaque types that is quite involved
to fix (see #129023).
In the meantime, this PR fixes the bug by delaying def creation for anon consts
whose bodies are macro invocations until after we expand the macro and know
what is inside it. This is accomplished by adding information to create the
anon const's def to the data in `Resolver.invocation_parents`.
r? `@BoxyUwU`
|
|
No analysis needs `Copy`, and `MaybeBorrowedLocals` is the only analysis
that needs `Clone`. In `locals_live_across_suspend_points` it gets
cloned so it can be used within a `MaybeRequiresStorage`.
|
|
unify `llvm-bitcode-linker`, `wasm-component-ld` and llvm-tools logics
To use the precompiled `ci-rustc` in CI, we need to install `llvm-bitcode-linker` and LLVM tools into ci-rustc's sysroot. Without them some CI pipelines may fail, as shown [here](https://github.com/rust-lang/rust/pull/122709#issuecomment-2334365988).
Blocker for https://github.com/rust-lang/rust/pull/122709
|
|
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #130101 (some const cleanup: remove unnecessary attributes, add const-hack indications)
- #130208 (Introduce `'ra` lifetime name.)
- #130263 (coverage: Simplify creation of sum counters)
- #130273 (more eagerly discard constraints on overflow)
- #130276 (Add test for nalgebra hang in coherence)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
...and remove the `const_arg_path` feature gate as a result. It was only
a stopgap measure to fix the regression that the new lowering introduced
(which should now be fixed by this PR).
|
|
Ever since #125915, some `ast::AnonConst`s turn into `hir::ConstArgKind::Path`s,
which don't have associated `DefId`s. To deal with the fact that we don't have
resolution information in `DefCollector`, we decided to implement a process
where if the anon const *appeared* to be trivial (i.e., `N` or `{ N }`), we
would avoid creating a def for it in `DefCollector`. If later, in AST lowering,
we realized it turned out to be a unit struct literal, or we were lowering it
to something that didn't use `hir::ConstArg`, we'd create its def there.
However, let's say we have a macro `m!()` that expands to a reference to a free
constant `FOO`. If we use `m!()` in the body of an anon const (e.g., `Foo<{ m!() }>`),
then in def collection, it appears to be a nontrivial anon const and we create
a def. But the macro expands to something that looks like a trivial const arg,
but is not, so in AST lowering we "fix" the mistake we assumed def collection
made and create a def for it. This causes a duplicate definition ICE.
The ideal long-term fix for this is a bit unclear. One option is to delay def
creation for all expression-like nodes until AST lowering (see #128844 for an
incomplete attempt at this). This would avoid issues like this one that are
caused by hacky workarounds. However, this approach has some downsides as well,
and the best approach is yet to be determined.
In the meantime, this PR fixes the bug by delaying def creation for anon consts
whose bodies are macro invocations until after we expand the macro and know
what is inside it. This is accomplished by adding information to create the
anon const's def to the data in `Resolver.invocation_parents`.
|
|
Add test for nalgebra hang in coherence
r? lcnr
|
|
more eagerly discard constraints on overflow
We always discard the results of overflowing goals inside of the trait solver. We previously did so when instantiating the response in `evaluate_goal`. Canonicalizing results only to later discard them is also inefficient :shrug:
It's simpler and nicer to debug to eagerly discard constraints inside of the query itself.
r? ``@compiler-errors``
|
|
coverage: Simplify creation of sum counters
A small and self-contained improvement, extracted from some larger changes that I'm still working on.
Ultimately I want to avoid creating these sum counter-expressions in some cases (in favour of just adding physical counters directly to the nodes we care about), so a good incremental move towards that is splitting the “gather edge counters” step out from the ”build a sum of those counters” step.
Creating an extra intermediate vector should have negligible cost (and coverage isn't exercised by the benchmark suite anyway). The removed logging is redundant with the `#[instrument(..)]` logging we already have on the underlying method calls.
|
|
Introduce `'ra` lifetime name.
`rustc_resolve` allocates many things in `ResolverArenas`. The lifetime used for references into the arena is mostly `'a`, and sometimes `'b`.
This commit changes it to `'rslv`, which is much more descriptive. The commit also changes the order of lifetimes on a couple of structs so that '`rslv` is second last, before `'tcx`, and does other minor renamings such as `'r` to `'a`.
r? ``@petrochenkov``
cc ``@oli-obk``
|
|
some const cleanup: remove unnecessary attributes, add const-hack indications
I learned that we use `FIXME(const-hack)` on top of the "const-hack" label. That seems much better since it marks the right place in the code and moves around with the code. So I went through the PRs with that label and added appropriate FIXMEs in the code. IMO this means we can then remove the label -- Cc ``@rust-lang/wg-const-eval.``
I also noticed some const stability attributes that don't do anything useful, and removed them.
r? ``@fee1-dead``
|
|
Update compiler-builtins to 0.1.125
This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are:
* https://github.com/rust-lang/compiler-builtins/pull/682
* https://github.com/rust-lang/compiler-builtins/pull/678
* https://github.com/rust-lang/compiler-builtins/pull/685
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #125060 (Expand documentation of PathBuf, discussing lack of sanitization)
- #129367 (Fix default/minimum deployment target for Aarch64 simulator targets)
- #130156 (Add test for S_OBJNAME & update test for LF_BUILDINFO cl and cmd)
- #130160 (Fix `slice::first_mut` docs)
- #130235 (Simplify some nested `if` statements)
- #130250 (Fix `clippy::useless_conversion`)
- #130252 (Properly report error on `const gen fn`)
- #130256 (Re-run coverage tests if `coverage-dump` was modified)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Re-run coverage tests if `coverage-dump` was modified
If the `coverage-dump` tool was modified, coverage tests should not be treated as up-to-date, because the tool's output might have changed.
Bootstrap already handles rebuilding the tool itself if its sources were changed, so all compiletest needs to do here is include the binary in the list of files whose timestamps are checked.
This should have no effect on non-coverage tests, because bootstrap won't pass the `--coverage-dump-path` flag, so the path in compiletest's config will be None.
|
|
Properly report error on `const gen fn`
Fixes #130232
Also removes some (what I thought were unused) functions, and fixes a bug in clippy where we considered `gen fn` to be the same as `fn` because it was only built to consider asyncness.
|
|
Fix `clippy::useless_conversion`
Self-explanatory. Probably the last clippy change I'll actually put up since this is the only other one I've actually seen in the wild.
|
