| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update more 2024 tests to remove -Zunstable-options
This removes `-Zunsable-options` from more tests that I missed in https://github.com/rust-lang/rust/pull/133349.
|
|
[rustdoc] Change impl items indent
Fixes https://github.com/rust-lang/rust/issues/131704.
| before | after |
|-|-|
|  |  |
Can be tested [here](https://rustdoc.crud.net/imperio/impl-items-indent/bar/struct.Bar.html).
r? `@notriddle`
|
|
Support `clobber_abi` in AVR inline assembly
This PR implements the `clobber_abi` part necessary to eventually stabilize the inline assembly for AVR. This is tracked in #93335.
This is heavily inspired by the sibling-PR #131310 for the MSP430. I've explained my reasoning in the first commit message in detail, which is reproduced below for easier reviewing:
This follows the [ABI documentation] of AVR-GCC:
> The [...] call-clobbered general purpose registers (GPRs) are registers that might be destroyed (clobbered) by a function call.
>
> - **R18–R27, R30, R31**
>
> These GPRs are call clobbered. An ordinary function may use them without restoring the contents. [...]
>
> - **R0, T-Flag**
>
> The temporary register and the T-flag in SREG are also call-clobbered, but this knowledge is not exposed explicitly to the compiler (R0 is a fixed register).
Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM.
Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways).
Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways.
[ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
r? ``@Amanieu``
``@rustbot`` label +O-AVR
|
|
Rollup of 7 pull requests
Successful merges:
- #132782 (improvements on initial sysroot and libdir finding logics)
- #133466 (Fix typos in pin.rs)
- #133492 (bootstrap: allow skipping steps with start of path)
- #133501 (support revealing defined opaque post borrowck)
- #133530 (Use consistent wording in docs, use is zero instead of is 0)
- #133538 (Better diagnostic for fn items in variadic functions)
- #133590 (Rename `-Zparse-only`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rename `-Zparse-only`
It's a misleading name.
r? ````@estebank````
|
|
Better diagnostic for fn items in variadic functions
closes #69232
|
|
support revealing defined opaque post borrowck
By adding a new `TypingMode::PostBorrowckAnalysis`. Currently only supported with the new solver and I didn't look into the way we replace `ReErased`. ``@compiler-errors`` mentioned that always using existentials may be unsound.
r? ``@compiler-errors``
|
|
Remove `HybridBitSet`
`HybridBitSet` was introduced under the name `HybridIdxSetBuf` way back in #53383 where it was a big win for NLL borrow checker performance. In #93984 the more flexible `ChunkedBitSet` was added. Uses of `HybridBitSet` have gradually disappeared (e.g. #116152) and there are now few enough that they can be replaced with `BitSet` or `ChunkedBitSet`, and `HybridBitSet` can be removed, cutting more than 700 lines of code.
r? `@Mark-Simulacrum`
|
|
This is in a test where the arrangement of backticks matters, but the
exact words do not.
|
|
Revert #133418 (Store coverage source regions as `Span`) due to regression #133606
This reverts commit adf9b5fcd1de43eaf0a779e10612caee8b47bede, reversing changes made to af1ca153d4aed5ffe22445273aa388a8d3f8f4ae.
Reverting #133418 due to regressions reported at #133606.
r? jieyouxu
|
|
This reverts commit adf9b5fcd1de43eaf0a779e10612caee8b47bede, reversing
changes made to af1ca153d4aed5ffe22445273aa388a8d3f8f4ae.
Reverting due to <https://github.com/rust-lang/rust/issues/133606>.
|
|
ensure JSON-defined targets are consistent
We have a `check_consistency` check that ensures some invariants which (presumably) the rest of the compiler relies on. However, JSON targets can easily be written in a way that violates those invariants. So this PR applies the same consistency check to JSON targets that we already enforce for built-in targets.
I have converted many of the assertions in that function to new macros that show a nice error instead of a panic; if people are okay with the general approach here, I can do that for the rest of the checks as well.
|
|
|
|
|
|
Enable -Zshare-generics for inline(never) functions
This avoids inlining cross-crate generic items when possible that are
already marked inline(never), implying that the author is not intending
for the function to be inlined by callers. As such, having a local copy
may make it easier for LLVM to optimize but mostly just adds to binary
bloat and codegen time. In practice our benchmarks indicate this is
indeed a win for larger compilations, where the extra cost in dynamic
linking to these symbols is diminished compared to the advantages in
fewer copies that need optimizing in each binary.
It might also make sense it expand this with other heuristics (e.g.,
`#[cold]`) in the future, but this seems like a good starting point.
FWIW, I expect that doing cleanup in where we make the decision
what should/shouldn't be shared is also a good idea. Way too
much code needed to be tweaked to check this. But I'm hoping
to leave that for a follow-up PR rather than blocking this on it.
|
|
I was surprised to find that running with `-Zparse-only` only parses the
crate root file. Other files aren't parsed because that happens later
during expansion.
This commit renames the option and updates the help message to make this
clearer.
|
|
Compiletest: add proc-macro header
This adds a `proc-macro` header to simplify using proc-macros, and to reduce boilerplate. This header works similar to the `aux-build` header where you pass a path for a proc-macro to be built.
This allows the `force-host`, `no-prefer-dynamic` headers, and `crate_type` attribute to be removed. Additionally it uses `--extern` like `aux_crate` (allows implicit `extern crate` in 2018) and `--extern proc_macro` (to place in the prelude in 2018).
~~This also includes a secondary change which defaults the edition of proc-macros to 2024. This further reduces boilerplate (removing `extern crate proc_macro;`), and allows using modern Rust syntax. I was a little on the fence including this. I personally prefer it, but I can imagine it might be confusing to others.~~ EDIT: Removed
Some tests were changed so that when there is a chain of dependencies A→B→C, that the `@ proc-macro` is placed in `B` instead of `A` so that the `--extern` flag works correctly (previously it depended on `-L` to find `C`). I think this is better to make the dependencies more explicit. None of these tests looked like the were actually testing this behavior.
There is one test that had an unexplained output change: `tests/ui/macros/same-sequence-span.rs`. I do not know why it changed, but it didn't look like it was particularly important. Perhaps there was a normalization issue?
This is currently not compatible with the rustdoc `build-aux-docs` header. It can probably be fixed, I'm just not feeling motivated to do that right now.
### Implementation steps
- [x] Document this new behavior in rustc-dev-guide once we figure out the specifics. https://github.com/rust-lang/rustc-dev-guide/pull/2149
|
|
This reduces code sizes and better respects programmer intent when
marking inline(never). Previously such a marking was essentially ignored
for generic functions, as we'd still inline them in remote crates.
|
|
always create `DefId`s for anon consts
but don't use them anywhere, we intentionally don't encode them in the crate metadata.
best reviewed by disabling whitespace.
This pretty much reimplements #133285 while adding the tests of #133455. Fixes #133064
r? `@BoxyUwU` `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
Trim extra space in 'repeated `mut`' diagnostic
Trim an extra space when removing repeated `mut`.
Also an extra test for even more repeated `mut`s
|
|
fix confusing diagnostic for reserved `##`
Closes #131615
|
|
Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18
Currently AArch64 inline assembly allows using x18 on ohos/trusty or with -Zfixed-x18.
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/asm/aarch64.rs#L74-L76
However, x18 is reserved in these environments and should not be allowed in the input/output operands of inline assemblies as it is in Android, Windows, etc..
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs#L19
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs#L18
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_codegen_llvm/src/llvm_util.rs#L764-L771
(As for ohos, +reserve-x18 is [redundant](https://github.com/llvm/llvm-project/commit/c417b7a695704d5bc3be23f34d1bfa505f5172de#diff-0ddf23e0bf2b28b2d05f842f087d1e6f694e8e06d1765e8d0f10d47fddcdff9c) since https://github.com/rust-lang/rust/commit/7a966b918870485e9b364e77f50c511f8c2cc275 that starting using llvm's ohos targets. So removed it from target-spec.)
This fix may potentially break the code for tier 2 target (aarch64-unknown-linux-ohos). (As for others, aarch64-unknown-trusty is tier 3 and -Zfixed-x18 is unstable so breaking them should be fine.)
However, in any case, it seems suspicious that the code that is broken by this was sound.
r? `@Amanieu`
`@rustbot` label O-AArch64 +A-inline-assembly
|
|
Support predicate registers (clobber-only) in Hexagon inline assembly
The result of the Hexagon instructions such as comparison, store conditional, etc. is stored in predicate registers (`p[0-3]`), but currently there is no way to mark it as clobbered in `asm!`.
This is also needed for `clobber_abi` (although implementing `clobber_abi` will require the addition of support for [several more register classes](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.cpp#L71-L90). see also https://github.com/rust-lang/rust/issues/93335#issuecomment-2395210055).
Refs:
- [Section 6 "Conditional Execution" in Qualcomm Hexagon V73 Programmer’s Reference Manual](https://docs.qualcomm.com/bundle/publicresource/80-N2040-53_REV_AB_Qualcomm_Hexagon_V73_Programmers_Reference_Manual.pdf#page=90)
- [Register definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.td#L155)
cc `@androm3da` (target maintainer of hexagon-unknown-{[none-elf](https://doc.rust-lang.org/nightly/rustc/platform-support/hexagon-unknown-none-elf.html#target-maintainers),[linux-musl](https://doc.rust-lang.org/nightly/rustc/platform-support/hexagon-unknown-linux-musl.html#target-maintainers)})
r? `@Amanieu`
`@rustbot` label +A-inline-assembly
(Currently there is no O-hexagon label...)
|
|
Fix clobber_abi in RV32E and RV64E inline assembly
Currently clobber_abi in RV32E and RV64E inline assembly is implemented using InlineAsmClobberAbi::RiscV, but broken since x16-x31 cannot be used in RV32E and RV64E.
```
error: cannot use register `x16`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x17`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x28`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x29`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x30`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x31`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
```
r? `@Amanieu`
`@rustbot` label O-riscv +A-inline-assembly
|
|
Don't type error if we fail to coerce `Pin<T>` because it doesnt contain a ref
Fixes https://github.com/rust-lang/rust/issues/133222. Also moves some tests into a directory for better bookkeeping.
r? eholk or re-roll
|
|
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #129409 (Expand std::os::unix::fs::chown() doc with a warning)
- #133320 (Add release notes for Rust 1.83.0)
- #133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
- #133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
- #133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
- #133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
- #133520 (Structurally resolve before applying projection in borrowck)
- #133534 (extend group-forbid-always-trumps-cli test)
- #133537 ([rustdoc] Fix new clippy lints)
- #133543 ([AIX] create shim for lgammaf_r)
- #133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
- #133550 (print generated doc paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
extend group-forbid-always-trumps-cli test
Test it not just for a lint group, but also an individual lint, or when mixing the lint and the group. And test both orders in which the flags could be passed.
|
|
r=lcnr
Structurally resolve before applying projection in borrowck
As far as I can tell, all other `.normalize` calls in borrowck are noops and can remain that way. This is the only one that actually requires structurally resolving the type.
r? lcnr
|
|
Check `xform_ret_ty` for WF in the new solver to improve method winnowing
This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:
```
impl Foo
where
WC1,
{
fn method()
where
WC2,
{}
}
```
We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)
This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?
r? lcnr
|
|
Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`
So in https://github.com/rust-lang/rust/pull/113182, I introduced a "diagnostics improvement" in the form of 473c88dfb69f95b2e8c5f71ba7f6b7b448d22dc2, which changes which signature we end up instantiating with placeholder regions and which signature we end up instantiating with fresh region vars so that we have placeholders corresponding to the names of the late-bound regions coming from the *impl*.
However, this is not sound, since now we're essentially no longer proving that *all* instantiations of the trait method are compatible with an instantiation of the impl method, but vice versa (which is weaker). Let's look at the example `tests/ui/impl-trait/in-trait/do-not-imply-from-trait-impl.rs`:
```rust
trait MkStatic {
fn mk_static(self) -> &'static str;
}
impl MkStatic for &'static str {
fn mk_static(self) -> &'static str { self }
}
trait Foo {
fn foo<'a: 'static, 'late>(&'late self) -> impl MkStatic;
}
impl Foo for str {
fn foo<'a: 'static>(&'a self) -> impl MkStatic + 'static {
self
}
}
fn call_foo<T: Foo + ?Sized>(t: &T) -> &'static str {
t.foo().mk_static()
}
fn main() {
let s = call_foo(String::from("hello, world").as_str());
println!("> {s}");
}
```
To collect RPITITs, we were previously instantiating the trait signature with infer vars (`fn(&'?0 str) -> ?1t` where `?1t` is the variable we use to infer the RPITIT) and the impl signature with placeholders (there are no late-bound regions in that signature, so we just have `fn(&'a str) -> Opaque`).
Equating the signatures works, since all we do is unify `?1t` with `Opaque` and `'?0` with `'a`. However, conceptually it *shouldn't* hold, since this definition is not valid for *all* instantiations of the trait method but just the one where `'0` (i.e. `'late`) is equal to `'a` :(
## So what
This PR effectively reverts 473c88dfb69f95b2e8c5f71ba7f6b7b448d22dc2 to fix the unsoundness.
Fixes #133427
Also fixes #133425, which is actually coincidentally another instance of this bug (but not one that is weaponized into UB, just one that causes an ICE in refinement checking).
|
|
compiler-errors:codegen-select-unconstrained-params, r=lcnr
Delay a bug when encountering an impl with unconstrained generics in `codegen_select`
Despite its name, `codegen_select` is what powers `Instance::try_resolve`, which is used in pre-codegen contexts to try to resolve a method where possible. One place that it's used is in the "recursion MIR lint" that detects recursive MIR bodies.
If we encounter an impl in `codegen_select` that contains unconstrained generic parameters, we expect that impl to caused an error to be reported; however, there's no temporal guarantee that this error is reported *before* we call `codegen_select`. This is what a delayed bug is *for*, and this PR makes us use a delayed bug rather than asserting something about errors already having been emitted.
Fixes #126646
|
|
|
|
Structurally resolve before matching on type of projection
Another missing structural resolve in closure upvar analysis. I think it's better to place the normalization here rather than trying to guarantee that all types returned by the expr use visitor are structurally normalized, which I don't think we do now. Thoughts?
r? lcnr
|
|
Structurally resolve before checking `!` in HIR typeck
Some more missing structural resolves in HIR typeck :>
r? lcnr
|
|
coverage: Store coverage source regions as `Span` until codegen
Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as `Span` instead.
In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because `Span` is smaller than 4x u32.
---
There should be no changes to coverage output.
|
|
Some more refactorings towards removing driver queries
Follow up to https://github.com/rust-lang/rust/pull/127184
## Custom driver breaking change
The `after_analysis` callback is changed to accept `TyCtxt` instead of `Queries`. The only safe query in `Queries` to call at this point is `global_ctxt()` which allows you to enter the `TyCtxt` either way. To fix your custom driver, replace the `queries: &'tcx Queries<'tcx>` argument with `tcx: TyCtxt<'tcx>` and remove your `queries.global_ctxt().unwrap().enter(|tcx| { ... })` call and only keep the contents of the closure.
## Custom driver deprecation
The `after_crate_root_parsing` callback is now deprecated. Several custom drivers are incorrectly calling `queries.global_ctxt()` from inside of it, which causes some driver code to be skipped. As such I would like to either remove it in the future or if custom drivers still need it, change it to accept an `&rustc_ast::Crate` instead.
|
|
|
|
|
|
|
|
Do not unify dereferences of shared borrows in GVN
Repost of https://github.com/rust-lang/rust/pull/132461, the last commit applies my suggestions.
Fixes https://github.com/rust-lang/rust/issues/130853
|
|
|
|
Allow injecting a profiler runtime into `#![no_core]` crates
An alternative to #133300, allowing `-Cinstrument-coverage` to be used with `-Zbuild-std`.
The incompatibility between `profiler_builtins` and `#![no_core]` crates appears to have been caused by profiler_builtins depending on core, and therefore conflicting with core (or minicore).
But that's a false dependency, because the profiler doesn't contain any actual Rust code. So we can just mark the profiler itself as `#![no_core]`, and remove the incompatibility error.
---
For context, the error was originally added by #79958.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #132979 (use `--exact` on `--skip` to avoid unintended substring matches)
- #133248 (CI: split x86_64-msvc-ext job)
- #133449 (std: expose `const_io_error!` as `const_error!`)
- #133453 (Commit license-metadata.json to git and check it's correct in CI)
- #133457 (miri: implement `TlsFree`)
- #133493 (do not constrain infer vars in `find_best_leaf_obligation`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
