| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Clippy Fix array-size-threshold config deserialization error
Complementary PR to https://github.com/rust-lang/rust/pull/108673 in order to also get this into the **next** beta.
r? ``@Mark-Simulacrum``
|
|
Fix another ICE in `point_at_expr_source_of_inferred_type`
Types coming from method probes must only be investigated *structurally*, since they often contain escaping infer variables from generalization and autoderef. We already have a hack in this PR that erases variables from types, so just use that.
Fixes #108664
The note attached to this error is pretty bad:
```
here the type of `primes` is inferred to be `[_]`
```
But that's unrelated to the PR.
---
Side-note: This is a pretty easy to trigger beta regression, so I've nominated it. Alternatively, I'm slightly inclined to remove this code altogether until it can be reformulated to be more accurate and less ICEy.
|
|
r=petrochenkov
Deny capturing late-bound non-lifetime param in anon const
Introduce a new AnonConstBoundary so we can detect when we capture a late-bound non-lifetime param with `non_lifetime_binders` enabled.
In the future, we could technically do something like introduce an early-bound parameter on the anon const, and stick the late-bound param in its substs (kinda like how we turn late-bound lifetimes in opaques into early-bound ones). But for now, just deny it so we don't ICE.
Fixes #108191
|
|
Feed queries on impl side for RPITITs when using lower_impl_trait_in_trait_to_assoc_ty
I've added a test for traits that were already working and what I think is probably the last bit of infrastructure work needed.
In following PRs I'm going to start adding things TDD style, tests and code that make it work.
r? `@compiler-errors`
|
|
Make `ExprKind` the first field in `thir::Expr`
This makes its `Debug` impl print it first which is useful, as it's the most important part when looking at an expr.
|
|
Put backtick content from rustdoc search errors into a <code> elements
Some screenshots of the result:
You can test it [here](https://rustdoc.crud.net/imperio/rustdoc-search-background/foo/index.html?search=%22).
r? ```@notriddle```
|
|
Explain compile-time vs run-time difference in env!() error message
This PR is clarifying error message of `env!()` based on this user question: https://users.rust-lang.org/t/environment-variable-out-dir-is-undefined/90067
It makes it clear that `env!()` is for env variables defined at compile-time. There's special-case help text for common Cargo build script variables.
I've also rearranged the code to avoid allocating error message on the happy path when the env var is defined.
|
|
r=WaffleLapkin
Point error span at Some constructor argument when trait resolution fails
This is a follow up to #108254 and #106477 which extends error span refinement to handle a case which I mistakenly believed was handled in #106477. The goal is to refine the error span depicted below:
```rs
trait Fancy {}
impl <T> Fancy for Option<T> where T: Iterator {}
fn want_fancy<F>(f: F) where F: Fancy {}
fn example() {
want_fancy(Some(5));
// (BEFORE) ^^^^^^^ `{integer}` is not an iterator
// (AFTER) ^ `{integer}` is not an iterator
}
```
I had used a (slightly more complex) example as an illustrative example in #108254 , but hadn't actually turned it into a test, because I had (incorrectly) believed at the time it was covered by existing behavior. It turns out that `Some` is slightly "special" in that it resolves differently from the other `enum` constructors I had tried, and therefore this test was actually broken.
I've now updated the tests to include this example, and fixed the code to correctly resolve the `Some` constructor so that the span of the error is reduced.
|
|
|
|
|
|
|
|
This makes its `Debug` impl print it first which is useful, as it's the
most important part when looking at an expr.
|
|
Revert stabilization of `#![feature(target_feature_11)]`
This reverts #99767 due to the presence of bugs #108645 and #108646.
cc `@joshtriplett`
cc tracking issue #69098
r? `@ghost`
|
|
Rollup of 5 pull requests
Successful merges:
- #108516 (Restrict `#[rustc_box]` to `Box::new` calls)
- #108575 (Erase **all** regions when probing for associated types on ambiguity in astconv)
- #108585 (Run compiler test suite in parallel on Fuchsia)
- #108606 (Add test case for mismatched open/close delims)
- #108609 (Highlight whole expression for E0599)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This reverts commit b379d216eefaba083a0627b1724d73f99d4bdf5c.
|
|
|
|
Highlight whole expression for E0599
Fixes #108603
This adds a secondary label to highlight the whole expression leading to the error. It also prevents empty labels being recognised as 'unexpected' by compiletest - otherwise, tests with NOTE annotations would pick up empty labels.
`@rustbot` label +A-diagnostics
|
|
Add test case for mismatched open/close delims
Fixes #104367
Fixes #105209
After landing https://github.com/rust-lang/rust/pull/108297, these issues are resolved.
|
|
Erase **all** regions when probing for associated types on ambiguity in astconv
Fixes #108562
|
|
Restrict `#[rustc_box]` to `Box::new` calls
Currently, `#[rustc_box]` can be applied to any call expression with a single argument. This PR only allows it to be applied to calls to `Box::new`
|
|
Update LLVM submodule
Fixes #105626
|
|
|
|
Add support for QNX Neutrino to standard library
This change:
- adds standard library support for QNX Neutrino (7.1).
- upgrades `libc` to version `0.2.139` which supports QNX Neutrino
`@gh-tr`
⚠️ Backtraces on QNX require https://github.com/rust-lang/backtrace-rs/pull/507 which is not yet merged! (But everything else works without these changes) ⚠️
Tested mainly with a x86_64 virtual machine (see qnx-nto.md) and partially with an aarch64 hardware (some tests fail due to constrained resources).
|
|
Merge two different equality specialization traits in `core`
Arrays and slices each had their own version of this, without a matching set of `impl`s.
Merge them into one (still-`pub(crate)`) `cmp::BytewiseEq` trait, so we can stop doing all these things twice.
And that means that the `[T]::eq` → `memcmp` specialization picks up a bunch of types where that previously only worked for arrays, so examples like <https://rust.godbolt.org/z/KjsG8MGGT> will use it now instead of emitting loops.
r? the8472
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #108143 (rustdoc: search by macro when query ends with `!`)
- #108394 (Make `x doc --open` work on every book)
- #108427 (Recover from for-else and while-else)
- #108462 (Fix `VecDeque::append` capacity overflow for ZSTs)
- #108568 (Make associated_item_def_ids for traits use an unstable option to also return associated types for RPITITs)
- #108604 (Add regression test for #107280)
- #108605 (Add regression test for #105821)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add regression test for #105821
Closes #105821
r? compiler-errors
|
|
Add regression test for #107280
Closes #107280
r? compiler-errors
|
|
Make associated_item_def_ids for traits use an unstable option to also return associated types for RPITITs
r? `@compiler-errors`
|
|
Recover from for-else and while-else
This recovers from attempts at writing for-else or while-else loops, which might help users coming from e.g. Python.
```rs
for _ in 0..0 {
// ...
} else {
// ...
}
```
Combined with trying to store it in a let binding, the current diagnostic can be a bit confusing. It mentions let-else and suggests wrapping the loop in parentheses, which the user probably doesn't want. let-else doesn't make sense for `for` and `while` loops, as they are of type `()` (which already is an irrefutable pattern and doesn't need let-else).
<details>
<summary>Current diagnostic</summary>
```rs
error: right curly brace `}` before `else` in a `let...else` statement not allowed
--> src/main.rs:4:5
|
4 | } else {
| ^
|
help: wrap the expression in parentheses
|
2 ~ let _x = (for _ in 0..0 {
3 |
4 ~ }) else {
|
```
</details>
Some questions:
- Can the wording for the error message be improved? Would "for...else loops are not allowed" fit better?
- Should we be more "conservative" in case we want to support this in the future (i.e. say "for...else loops are **currently** not allowed/supported")?
- Is there a better way than storing a `&'static str` for the loop type? It is used for substituting the placeholder in the locale file (since it can emit either `for...else` or `while...else`). Maybe there is an enum I could use that I couldn't find
|
|
r=GuillaumeGomez
rustdoc: search by macro when query ends with `!`
Related to #96399
Note: the `never` type alias is tested in [`/tests/rustdoc-js-std/alias-3.js`](https://github.com/notriddle/rust/blob/08ad401633037cc226b3806a3c5f48c2f34703bf/tests/rustdoc-js-std/alias-3.js)
## Before
## After
|
|
|
|
|
|
Name LLVM anonymous constants by a hash of their contents
This makes the names stable between different versions of a crate unlike the `AllocId` naming, making LLVM IR comparisons with `llvm-diff` more practical.
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Add `Option::as_`(`mut_`)`slice`
This adds the following functions:
* `Option<T>::as_slice(&self) -> &[T]`
* `Option<T>::as_mut_slice(&mut self) -> &[T]`
The `as_slice` and `as_mut_slice_mut` functions benefit from an optimization that makes them completely branch-free. ~~Unfortunately, this optimization is not available on by-value Options, therefore the `into_slice` implementations use the plain `match` + `slice::from_ref` approach.~~
Note that the optimization's soundness hinges on the fact that either the niche optimization makes the offset of the `Some(_)` contents zero or the mempory layout of `Option<T>` is equal to that of `Option<MaybeUninit<T>>`.
The idea has been discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Option.3A.3Aas_slice). Notably the idea for the `as_slice_mut` and `into_slice´ methods came from `@cuviper` and `@Sp00ph` hardened the optimization against niche-optimized Options.
The [rust playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=74f8e4239a19f454c183aaf7b4a969e0) shows that the generated assembly of the optimized method is basically only a copy while the naive method generates code containing a `test dx, dx` on x86_64.
---
EDIT from reviewer: ACP is https://github.com/rust-lang/libs-team/issues/150
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #108376 (compiler/rustc_session: fix sysroot detection logic)
- #108400 (add llvm cgu instructions stats to perf)
- #108496 (fix #108495, postfix decrement and prefix decrement has no warning)
- #108505 (Further unify validity intrinsics)
- #108520 (Small cleanup to `one_bound_for_assoc_type`)
- #108560 (Some `infer/mod.rs` cleanups)
- #108563 (Make mailmap more correct)
- #108564 (Fix `x clean` with specific paths)
- #108571 (Add contains_key to SortedIndexMultiMap)
- #108578 (Update Fuchsia platform team members)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix #108495, postfix decrement and prefix decrement has no warning
Fixes #108495
|
|
Only look for param in item's generics if it actually comes from generics
Record whether a `hir::GenericParam` comes from an item's generics, or from a `for<...>` binder. Then, only look for the param in `object_lifetime_default` if it actually comes from the item's generics.
Fixes #108177
|
|
Descriptive error when users try to combine RPITIT/AFIT with specialization
Previously we failed with some esoteric error like:
```
error[E0053]: method `foo` has an incompatible type for trait
--> $DIR/dont-project-to-specializable-projection.rs:14:35
|
LL | default async fn foo(_: T) -> &'static str {
| ^^^^^^^^^^^^ expected associated type, found future
|
note: type in trait
--> $DIR/dont-project-to-specializable-projection.rs:10:27
|
LL | async fn foo(_: T) -> &'static str;
| ^^^^^^^^^^^^
= note: expected signature `fn(_) -> impl Future<Output = &'static str>`
found signature `fn(_) -> impl Future<Output = &'static str>`
```
Now we error like:
```
error: async associated function in trait cannot be specialized
--> $DIR/dont-project-to-specializable-projection.rs:14:5
|
LL | default async fn foo(_: T) -> &'static str {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: specialization behaves in inconsistent and surprising ways with `#![feature(async_fn_in_trait)]`, and for now is disallowed
```
|
|
Remove the `capture_disjoint_fields` feature
As best I can tell, this was stabilized for Edition 2021 in #88126 but the feature was never removed.
|
|
Exit when there are unmatched delims to avoid noisy diagnostics
From https://github.com/rust-lang/rust/pull/104012#issuecomment-1311764832
r? ``@petrochenkov``
|
|
This adds the following functions:
* `Option<T>::as_slice(&self) -> &[T]`
* `Option<T>::as_slice_mut(&mut self) -> &[T]`
The `as_slice` and `as_slice_mut` functions benefit from an
optimization that makes them completely branch-free.
Note that the optimization's soundness hinges on the fact that either
the niche optimization makes the offset of the `Some(_)` contents zero
or the mempory layout of `Option<T>` is equal to that of
`Option<MaybeUninit<T>>`.
|
|
|
|
|
|
|
