| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
pnkfelix:issue-80949-short-term-resolution-via-revert-of-pr-78373, r=matthewjasper
Revert 78373 ("dont leak return value after panic in drop")
Short term resolution for issue #80949.
Reopen #47949 after this lands.
(We plan to fine-tune PR #78373 to not run into this problem.)
|
|
introduce future-compatibility warning for forbidden lint groups
We used to ignore `forbid(group)` scenarios completely. This changed in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.
r? ``@Mark-Simulacrum``
|
|
Remove incorrect `delay_span_bug`
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix (but not close) #80207.
|
|
Make hitting the recursion limit in projection non-fatal
This change was originally made in #80246 to avoid future (effectively) infinite loop bugs in projections,
but wundergraph relies on rustc recovering here.
cc #80953
r? `@nikomatsakis`
|
|
When normalizing a projection which results in a cycle, we would
cache the result of `project_type` without the nested obligations
(because they're not needed for inference). This would result in
the nested obligations only being handled once in fulfill, which
would avoid the cycle error.
Fixes #79714, a regresion from #79305 caused by the removal of
`get_paranoid_cache_value_obligation`.
|
|
This avoid the hang/oom from #79714
|
|
wesleywiser:revert_missing_fragment_specifier_hard_error, r=Mark-Simulacrum
Revert missing fragment specifier hard error
Closes #76605
Reopens #40107
r? `@Mark-Simulacrum`
|
|
Implemented a compiler diagnostic for move async mistake
Fixes #79694
First time contributing, so I hope I'm doing everything right.
(If not, please correct me!)
This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it.
Checked code:
```rust
fn main() {
move async { };
}
```
Previous output:
```txt
PS C:\Repos\move_async_test> cargo build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: expected one of `|` or `||`, found keyword `async`
--> src\main.rs:2:10
|
2 | move async { };
| ^^^^^ expected one of `|` or `||`
error: aborting due to previous error
error: could not compile `move_async_test`
```
New output:
```txt
PS C:\Repos\move_async_test> cargo +dev build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: the order of `move` and `async` is incorrect
--> src\main.rs:2:13
|
2 | let _ = move async { };
| ^^^^^^^^^^
|
help: try switching the order
|
2 | let _ = async move { };
| ^^^^^^^^^^
error: aborting due to previous error
error: could not compile `move_async_test`
```
Is there a file/module where these kind of things are tested?
Would love some feedback 😄
|
|
Added better error message for shared borrow treated as unique for purposes of lifetimes
Part of Issue #76630
r? `@jyn514`
|
|
Deprecate atomic compare_and_swap method
Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443).
It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find, and even if this PR does not go through it can act as a place where people can find out about the decision being reverted.
Atomic operations are hard to understand, very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better.
Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes, but I wanted to start somewhere. Most of it is just copied from the RFC.
The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations.
The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.
|
|
Rollup of 17 pull requests
Successful merges:
- #80136 (Add test for issue #74824)
- #80203 (Edit rustc_middle::lint::LintSource docs)
- #80204 (docs: Edit rustc_middle::ty::query::on_disk_cache)
- #80219 (Fix labels for 'Library Tracking Issue' template)
- #80222 (Fix rustc-std-workspace-core documentation)
- #80223 (docs: Fix outdated crate reference)
- #80225 (Add module-level docs to rustc_middle::ty)
- #80241 (Fix typo)
- #80248 (Remove `I-prioritize` from Zulip topic)
- #80266 (Remove redundant test)
- #80272 (rustc_span: Provide a reserved identifier check for a specific edition)
- #80285 (Update books)
- #80286 (docs: Edit rustc_middle::middle::privacy)
- #80297 (Add some intra-doc links to compiler docs)
- #80298 (Improve the code quality by using matches macro)
- #80299 (Turn helper method into a closure)
- #80302 (docs: Update rustc_middle::middle::region::ScopeTree)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add test for issue #74824
It was fixed a while ago, but doesn't have a test.
Closes #74824
|
|
|
|
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
|
|
|
|
Rename `overlapping_patterns` lint
As discussed in https://github.com/rust-lang/rust/issues/65477. I also tweaked a few things along the way.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
|
|
Acknowledge that `[CONST; N]` is stable
When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749, accidentally, the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable:
```rust
const EMPTY: Vec<i32> = Vec::new();
pub const fn bar() -> [Vec<i32>; 2] {
[EMPTY; 2]
}
fn main() {
let x = bar();
}
```
In contrast, if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY,).0`), this would have failed.
We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)), so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved).
Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]`, or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor, it should run in the former case (but currently doesn't, due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the `let`-expansion does *not* work in general, for `N > 1`.
Cc `@rust-lang/lang` `@rust-lang/wg-const-eval`
Cc https://github.com/rust-lang/rust/issues/49147
|
|
Ran the tidy check
Following the diagnostic guide better
Diagnostic generation is now relegated to its own function in the diagnostics module.
Added tests
Fixed the ui test
|
|
r=davidtwco
Fix pretty printing an AST representing `&(mut ident)`
The PR fixes a misguiding help diagnostic in the parser that I reported in #80186. I discovered that the parsers recovery and reporting logic was correct but the pretty printer produced wrong code for the example. (Details in https://github.com/rust-lang/rust/issues/80186#issuecomment-748498676)
Example:
```rust
#![allow(unused_variables)]
fn main() {
let mut &x = &0;
}
```
The AST fragment
`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), Mutability::Not)`
was printed to be `&mut ident`. But this wouldn't round trip through parsing again, because then it would be:
`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Not), ..), Mutability::Mut)`
Now the pretty-printer prints `&(mut ident)`. Reparsing that code results in the AST fragment
`PatKind::Ref(PatKind::Paren(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..)), Mutability::Not)`
which I think should behave like the original pattern.
Old diagnostic:
```
error: `mut` must be attached to each individual binding
--> src/main.rs:3:9
|
3 | let mut &x = &0;
| ^^^^^^ help: add `mut` to each binding: `&mut x`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
New diagnostic:
```
error: `mut` must be attached to each individual binding
--> src/main.rs:3:9
|
3 | let mut &x = &0;
| ^^^^^^ help: add `mut` to each binding: `&(mut x)`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
Fixes #80186
|
|
Handle desugaring in impl trait bound suggestion
Fixes #79843.
When an associated type of a generic function parameter needs extra bounds, the diagnostics may suggest replacing an `impl Trait` with a named type parameter so that it can be referenced in the where clause. On stable and nightly, the suggestion can be malformed, for instance transforming:
```rust
async fn run(_: &(), foo: impl Foo) -> std::io::Result<()>
```
Into:
```rust
async fn run(_: &, F: Foo(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Where we want something like:
```rust
async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
The problem is that the elided lifetime of `&()` is added as a generic parameter when desugaring the async fn; the suggestion code sees this as an existing generic parameter and tries to use its span as an anchor to inject `F` into the parameter list. There doesn't seem to be an entirely principled way to check which generic parameters in the HIR were explicitly named in the source, so this commit changes the heuristics when generating the suggestion to only consider type parameters whose spans are contained within the span of the `Generics` when determining how to insert an additional type parameter into the declaration. (And to be safe it also excludes parameters whose spans are marked as originating from desugaring, although that doesn't seem to handle this elided lifetime.)
|
|
also const-check FakeRead
We need to const-check all statements, including `FakeRead`, to avoid issues like https://github.com/rust-lang/rust/issues/77694.
Fixes https://github.com/rust-lang/rust/issues/77694.
r? ``@oli-obk``
|
|
Fix ICE when lookup method in trait for type that have bound vars
Closes #77910
|
|
Turn quadratic time on number of impl blocks into linear time
Previously, if you had a lot of inherent impl blocks on a type like:
```Rust
struct Foo;
impl Foo { fn foo_1() {} }
// ...
impl Foo { fn foo_100_000() {} }
```
The compiler would be very slow at processing it, because
an internal algorithm would run in O(n^2), where n is the number
of impl blocks. Now, we add a new algorithm that allocates but
is faster asymptotically.
Comparing rustc nightly with a local build of rustc as of this PR (results in seconds):
| N | real time before | real time after |
| - | - | - |
| 4_000 | 0.57 | 0.46 |
| 8_000 | 1.31 | 0.84 |
| 16_000 | 3.56 | 1.69 |
| 32_000 | 10.60 | 3.73 |
I've tuned up the numbers to make the effect larger than the startup noise of rustc, but the asymptotic difference should hold for smaller n as well.
Note: current state of the PR omits error messages if there are other errors present already. For now, I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!
|
|
Mark `-1` as an available niche for file descriptors
Based on discussion from <https://internals.rust-lang.org/t/can-the-standard-library-shrink-option-file/12768>, the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen, particularly on Linux, but would not necessarily be portable.
This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the "upper" bound, which is actually -1, to be expressed in two's complement.
|
|
|
|
|
|
|
|
`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), ..)`
is an AST representing `&(mut ident)`. It was errorneously printed as
`&mut ident` which reparsed into a syntactically different AST.
This affected help diagnostics in the parser.
|
|
Make BoundRegion have a kind of BoungRegionKind
Split from #76814
Also includes making `replace_escaping_bound_vars` only return `T`
Going to r? `@lcnr`
Feel free to reassign
|
|
or_patterns: implement :pat edition-specific behavior
cc #54883 `@joshtriplett`
This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090.
I believe this can unblock stabilization of or_patterns.
r? `@petrochenkov`
|
|
|
|
const_evaluatable_checked: fix occurs check
fixes #79615
this is kind of a hack because we use `TypeRelation` for both the `Generalizer` and the `ConstInferUnifier` but i am not sure if there is a useful way to disentangle this without unnecessarily duplicating some code.
The error in the added test is kind of unavoidable until we erase the unused substs of `ConstKind::Unevaluated`. We talked a bit about this in the cg lazy norm meeting (https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/lazy_normalization_consts)
|
|
|
|
Improve and fix diagnostics of exhaustiveness checking
Primarily, this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics:
```rust
match &[][..] {
[true] => {}
[true // detected as unreachable but that's not true
| false, ..] => {}
_ => {}
}
match (true, None) {
(true, Some(_)) => {}
(false, Some(true)) => {}
(true | false, None | Some(true // should be detected as unreachable
| false)) => {}
}
```
I did not measure any perf impact. However, I suspect that [`616ba9f`](https://github.com/rust-lang/rust/pull/80104/commits/616ba9f9f7f5845777a36e1a41a515e6c33a8776) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed.
EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x)
r? `@varkor`
`@rustbot` label +A-exhaustiveness-checking
|
|
|
|
Revert change to trait evaluation order
This change breaks some code and doesn't appear to enable any new code.
closes #79902
r? `@nikomatsakis`
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #78083 (Stabilize or_insert_with_key)
- #79211 (Add the "async" and "promise" doc aliases to `core::future::Future`)
- #79612 (Switch some links in compiler/ to intra-doc links)
- #80068 (Add `&mut` as an alias for 'reference' primitive)
- #80129 (docs: Edit rustc_ast::token::Token)
- #80133 (Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhere)
- #80155 (Fix typo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhere
Fixes #79971
|
|
passes: prohibit invalid attrs on generic params
Fixes #78957.
This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity.
r? `@lcnr`
|
|
Gracefully handle mistyping -> as => in function return type
Fixes #77019
|
|
|
|
|
|
|
|
`SpanSet` is heavily inspired from `DefIdForest`.
|
|
|
|
Don't allow `const` to begin a nonterminal
Fixes #79908.
Thanks to Vadim Petrochenkov who [told me what the fix was][z]!
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/finding.20which.20macro.20rule.20to.20use/near/220240422
r? ``@petrochenkov``
|
|
Change the message for `if_let_guard` feature gate
`if-let` guards are now implemented by #79051 🎉
Thanks ``@camelid`` for pointing this out 🙂
|
