| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Warn on redundant `--cfg` directive when revisions are used
r? ``@jieyouxu``
Fixes #131390
Not sure of the best way to test this
|
|
Add codegen test for branchy bool match
Closes #108395
|
|
Stop inverting expectation in normalization errors
We have some funky special case logic to invert the expectation and actual type for normalization errors depending on their cause code. IMO most of the error messages get better, except for `try {}` blocks' type expectations. I think that these need to be special cased in some other way, rather than via this hack.
Fixes #131763
|
|
Make sure that outer opaques capture inner opaques's lifetimes even with precise capturing syntax
When lowering an opaque, we must capture and duplicate all of the lifetimes in the opaque's bounds to correctly lower the opaque's bounds. We do this *even if* the lifetime is not captured according to the `+ use<>` precise capturing bound; in that case, we will later reject that captured lifetime. For example, Given an opaque like `impl Sized + 'a + use<>`, we will still duplicate `'a` but later error that it is not mentioned in the `use<>` bound.
The current heuristic was not properly handling cases like:
```
//@ edition: 2024
fn foo<'a>() -> impl Trait<Assoc = impl Trait2> + use<> {}
```
Which forces the outer `impl Trait` to capture `'a` since `impl Trait2` *implicitly* captures `'a` due to the new lifetime capture rules for edition 2024. We were only capturing lifetimes syntactically mentioned in the bounds. (Note that this still is an error; we just need to capture `'a` so it is handled later in the compiler correctly -- hence the ICE in #131769 where a late-bound lifetime was being referenced outside of its binder).
This PR reworks the way we collect lifetimes to capture and duplicate in AST lowering to fix this.
Fixes #131769
|
|
Remove invalid help diagnostics for const pointer
Partially addresses #127562
|
|
r=jieyouxu
warn less about non-exhaustive in ffi
Bindgen allows generating `#[non_exhaustive] #[repr(u32)]` enums. This results in nonintuitive nonlocal `improper_ctypes` warnings, even when the types are otherwise perfectly valid in C.
Adjust for actual tooling expectations by avoiding warning on simple enums with only unit variants.
Closes https://github.com/rust-lang/rust/issues/116831
|
|
precise capturing syntax
|
|
Rollup of 8 pull requests
Successful merges:
- #127462 (std: uefi: Add basic Env variables)
- #131537 (Fix range misleading field access)
- #131838 (bootstrap: allow setting `--jobs` in config.toml)
- #131890 (Update `use` keyword docs to describe precise capturing)
- #131899 (Mark unexpected variant res suggestion as having placeholders)
- #131908 (rustdoc: Switch from FxHash to sha256 for static file hashing.)
- #131916 (small interpreter error cleanup)
- #131919 (zero-sized accesses are fine on null pointers)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix range misleading field access
Fixes #131471 by checking if the range-start is a literal.
|
|
Return values larger than 2 registers using a return area pointer
LLVM and Cranelift disagree about how to return values that don't fit in the registers designated for return values. LLVM will force the entire return value to be passed by return area pointer, while Cranelift will look at each IR level return value independently and decide to pass it in a register or not, which would result in the return value being passed partially in registers and partially through a return area pointer.
While Cranelift may need to be fixed as the LLVM behavior is generally more correct with respect to the surface language, forcing this behavior in rustc itself makes it easier for other backends to conform to the Rust ABI and for the C ABI rustc already handles this behavior anyway.
In addition LLVM's decision to pass the return value in registers or using a return area pointer depends on how exactly the return type is lowered to an LLVM IR type. For example `Option<u128>` can be lowered as `{ i128, i128 }` in which case the x86_64 backend would use a return area pointer, or it could be passed as `{ i32, i128 }` in which case the x86_64 backend would pass it in registers by taking advantage of an LLVM ABI extension that allows using 3 registers for the x86_64 sysv call conv rather than the officially specified 2 registers.
This adjustment is only necessary for the Rust ABI as for other ABI's the calling convention implementations in rustc_target already ensure any return value which doesn't fit in the available amount of return registers is passed in the right way for the current target.
Helps with https://github.com/rust-lang/rustc_codegen_cranelift/issues/1525
cc https://github.com/bytecodealliance/wasmtime/issues/9250
|
|
|
|
|
|
|
|
Fixes #131471 by checking if the range-start is a literal.
|
|
Never emit `vptr` for empty/auto traits
Emiting `vptr`s for empty/auto traits is unnecessary (#114942) and causes unsoundness in `trait_upcasting` (#131813). This PR should ensure that we never emit vtables for such traits. See the linked issues for more details.
I'm not sure if I can add tests for the vtable layout. So this PR only adds tests for the soundness hole (i.e., the segmentation fault will disappear after this PR).
Fixes #114942
Fixes #131813
Cc #65991 (tracking issue for `trait_upcasting`)
r? `@WaffleLapkin` (per https://github.com/rust-lang/rust/issues/131813#issuecomment-2419969745)
|
|
Dont ICE when computing coverage of synthetic async closure body
I'm not totally certain if this is *right*, but at least it doesn't ICE.
The issue is that we end up generating two MIR bodies for each async closure, since the `FnOnce` and `Fn`/`FnMut` implementations have different borrowing behavior of their captured variables. They should ideally both contribute to the coverage, since those MIR bodies are (*to the user*) the same code and should have no behavioral differences.
This PR at least suppresses the ICEs, and then I guess worst case we can fix this the right way later.
r? Zalathar or re-roll
Fixes #131190
|
|
Regression test for AVR `rjmp` offset
This adds a regression test for #129301 by minimizing the code in the linked issue and putting it into a `#![no_core]`-compatible format, so that it can easily be used within an `rmake`-test. This needs to be a `rmake` test (opposed to a `tests/assembly` one), since the linked issue describes, that the problem only occurs if the code is directly compiled. Note, that `lld` is used instead of `avr-gcc`; see the [comments](https://github.com/rust-lang/rust/pull/131755#issuecomment-2416469675) [below](https://github.com/rust-lang/rust/pull/131755#issuecomment-2417160045).
Closes #129301.
To show, that the test actually catches the wrong behavior, this can be tested with a faulty rustc:
```bash
$ rustup install nightly-2024-08-19
$ rustc +nightly-2024-08-19 -C opt-level=s -C panic=abort --target avr-unknown-gnu-atmega328 -Clinker=build/x86_64-unknown-linux-gnu/ci-llvm/bin/lld -Clink-arg='--entry=main' -o compiled tests/run-make/avr-rjmp-offset/avr-rjmp-offsets.rs
$ llvm-objdump -d compiled | grep '<main>' -A 6
000110b4 <main>:
110b4: 81 e0 ldi r24, 0x1
110b6: 92 e0 ldi r25, 0x2
110b8: 85 b9 out 0x5, r24
110ba: 95 b9 out 0x5, r25
110bc: fe cf rjmp .-4
```
One can see, that the wrong label offset (`4` instead of `6`) is produced, which would trigger an assertion in the test case.
This would be a good candidate for using the `minicore` proposed in #130693. Since this is not yet merged, there is a FIXME.
r? Patryk27
I think, you are the yet-to-be official target maintainer, hence I'll assign to you.
`@rustbot` label +O-AVR
|
|
|
|
Allow dropping dyn principal
Revival of #126660, which was a revival of #114679. Fixes #126313.
Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`.
cc `@compiler-errors` `@Jules-Bertholet`
r? `@lcnr`
|
|
|
|
|
|
Avoid superfluous UB checks in `IndexRange`
`IndexRange::len` is justified as an overall invariant, and
`take_prefix` and `take_suffix` are justified by local branch
conditions. A few more UB-checked calls remain in cases that are only
supported locally by `debug_assert!`, which won't do anything in
distributed builds, so those UB checks may still be useful.
We generally expect core's `#![rustc_preserve_ub_checks]` to optimize
away in user's release builds, but the mere presence of that extra code
can sometimes inhibit optimization, as seen in #131563.
|
|
Add `must_use` to `CommandExt::exec`
[CommandExt::exec](https://fburl.com/0qhpo7nu) returns a `std::io::Error` in the case exec fails, but its not currently marked as `must_use` making it easy to accidentally ignore it.
This PR adds the `must_use` attributed here as i think it fits the definition in the guide of [When to add #[must_use]](https://std-dev-guide.rust-lang.org/policy/must-use.html#when-to-add-must_use)
|
|
|
|
|
|
llvm: Tolerate propagated range metadata
llvm/llvm-project#91101 propagates range information across inlining, resulting in more metadata in this test. Tolerate the range metadata if it appears.
``@rustbot:`` label +llvm-main
r? ``@durin42``
Please wait a moment before approving, putting the llvm-main tag on it to make sure it fixes the integration test.
|
|
cleanup canonical queries
best reviewed commit by commit. adding `CanonicalQueryInput` to stop returning `defining_opaque_types` in query responses is the most involved change here.
r? ``@compiler-errors``
|
|
r=aDotInTheVoid
rustdoc-JSON: Rename "object safe" to "dyn compatible"
~~Blocked: Sits atop #131594. Only the last commit is relevant.~~ (rebased)
Part of #130852.
r? aDotInTheVoid or rustdoc
|
|
Change orphan hint from "only" to "any uncovered type inside..."
Fix #128390
|
|
|
|
This fixes the [build error] caused by the `avr-gcc` (used as linker)
not being available in the Rust CI. This is a viable solution, which
shows the wrong/right behavior and, since no functions from `libgcc` are
called, does not produce errors. This was discussed [here]. Another
small problem is, that `lld` doesn't link the correct startup-code by
default. This is not a problem for this test (since it does not actually
use anything the startup code is needed for (no variables, no stack, no
interrupts)), but this causes the `main`-function to be removed by the
default flag `--gc-sections`. Therefore the `rmake`-driver also adds the
linker flag `--entry=main` to mark the `main`-function as the entry
point and thus preventing it from getting removed. The code would work
on a real AVR device.
[build error]: https://github.com/rust-lang/rust/pull/131755#issuecomment-2415127952
[here]: https://github.com/rust-lang/rust/pull/131755#issuecomment-2416469675
|
|
Make destructors on `extern "C"` frames to be executed
This would make the example in #123231 print "Noisy Drop". I didn't mark this as fixing the issue because the behaviour is yet to be spec'ed.
Tracking:
- https://github.com/rust-lang/rust/issues/74990
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #130989 (Don't check unsize goal in MIR validation when opaques remain)
- #131657 (Rustfmt `for<'a> async` correctly)
- #131691 (Delay ambiguous intra-doc link resolution after `Cache` has been populated)
- #131730 (Refactor some `core::fmt` macros)
- #131751 (Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe)
- #131753 (Unify `secondary_span` and `swap_secondary_and_primary` args in `note_type_err`)
- #131776 (Emscripten: Xfail backtrace ui tests)
- #131777 (Fix trivially_copy_pass_by_ref in stable_mir)
- #131778 (Fix needless_lifetimes in stable_mir)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
llvm/llvm-project#91101 propagates range information across inlining,
resulting in more metadata in this test. Tolerate the range metadata if
it appears.
|
|
Emscripten: Xfail backtrace ui tests
It is possible to link libunwind and use the normal backtrace code, but it fails to symbolize stack traces. I investigated and could get the list of instruction pointers and symbol names, but I'm not sure how to use the dwarf info to map from instruction pointer to source location. In any case, fixing this is not a high priority.
See https://github.com/rust-lang/rust/issues/131738
r?jieyouxu
|
|
Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe
We need to structurally resolve the lhs and rhs of the coercion. Also, renaming the method so it's less ambiguous about what it's doing... the word "may" gives more clear signal that it has false positives imo.
r? lcnr
|
|
r=notriddle
Delay ambiguous intra-doc link resolution after `Cache` has been populated
Fixes https://github.com/rust-lang/rust/issues/130233.
I was getting nowhere with #130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.
r? ```@notriddle```
|
|
Don't check unsize goal in MIR validation when opaques remain
Similarly to `mir_assign_valid_types`, let's just skip when there are opaques. Fixes #130921.
|
|
Rollup of 8 pull requests
Successful merges:
- #130822 (Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`.)
- #131381 (Implement edition 2024 match ergonomics restrictions)
- #131594 (rustdoc: Rename "object safe" to "dyn compatible")
- #131686 (Add fast-path when computing the default visibility)
- #131699 (Try to improve error messages involving aliases in the solver)
- #131757 (Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind)
- #131783 (Fix explicit_iter_loop in rustc_serialize)
- #131788 (Fix mismatched quotation mark)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix mismatched quotation mark
|
|
Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind
The lint-non-snake-case-crate test may emit a warning in stderr if the target does not support unwinding
```
warning: building proc macro crate with `panic=abort` may crash the compiler should the proc-macro panic
```
Consequently, the test will fail on targets that don't support unwinding as written.
This change modifies the expected stderr for lint-non-snake-case-crate in the proc_macro_ to ignore lines that indicate a warning was emitted.
|
|
Try to improve error messages involving aliases in the solver
1. Treat aliases as rigid only if it may not be defined and it's well formed (i.e. for projections, its trait goal is satisfied).
2. Record goals that are related to alias normalization under a new `GoalKind`, so we can look into them in the `BestObligation` visitor.
3. Try to deduplicate errors due to self types of goals that are un-normalizable aliases.
r? lcnr
|
|
rustdoc: Rename "object safe" to "dyn compatible"
Supersedes #126554:
1. In line with [T-lang's latest resolution](https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118).
2. More comprehensive: Not only updates user-facing text but also source code.
Part of #130852.
Doesn't update rustdoc-JSON (will be filed separately).
r? `@notriddle` (rust-lang/lang-team#286) `@GuillaumeGomez` (for visibility)
|
|
Implement edition 2024 match ergonomics restrictions
This implements the minimalest version of [match ergonomics for edition 2024](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html). This minimal version makes it an error to ever reset the default binding mode. The implemented proposal is described precisely [here](https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q#RFC-3627-nano), where it is called "RFC 3627-nano".
Rules:
- Rule 1C: When the DBM (default binding mode) is not `move` (whether or not behind a reference), writing `mut`, `ref`, or `ref mut` on a binding is an error.
- Rule 2C: Reference patterns can only match against references in the scrutinee when the DBM is `move`.
This minimal version is forward-compatible with the main proposals for match ergonomics 2024: [RFC3627](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html) itself, the alternative [rule 4-early variant](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html), and [others](https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q). The idea is to give us more time to iron out a final proposal.
This includes a migration lint that desugars any offending pattern into one that doesn't make use of match ergonomics. Such patterns have identical meaning across editions.
This PR insta-stabilizes the proposed behavior onto edition 2024.
r? `@ghost`
Tracking:
- https://github.com/rust-lang/rust/issues/123076
|
|
Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`.
Relevant tracking issue: #130823
The `core::ptr::NonNull` type should have the convenience constructors `from_ref` and `from_mut` for parity with `core::ptr::from_ref` and `core::ptr::from_mut`.
Although the type in question already implements `From<&T>` and `From<&mut T>`, these new functions also carry the ability to be used in constant expressions (due to not being behind a trait).
|
|
The new `rmake`-content asserts the exact assembly sequence for the loop
preventing false-negatives if some instructions would change and thus
the label offset might need to change.
|
