https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.78.0 2024-03-14T17:32:54+00:00 2024-03-14T17:32:54+00:00 Trevor Gross tmgross@umich.edu 2024-03-03T02:46:50+00:00 urn:sha1:2529bf2650ee548eb170822816aadacaa1ca05d2 Superceded by feature gate tests. 2024-03-12T20:32:21+00:00 Daniel Sedlak daniel@sedlak.dev 2024-03-12T18:23:53+00:00 urn:sha1:eab1f30c297027f2349ecd1322573ae3b5c9d668 2024-03-11T16:29:35+00:00 Jubilee 46493976+workingjubilee@users.noreply.github.com 2024-03-11T16:29:35+00:00 urn:sha1:05ff86c389c206c668c27d4bba531a21d9c12065 Improve diagnostics for parenthesized type arguments Fixes #120892 r? fmease 2024-03-09T21:15:50+00:00 Daniel Sedlak daniel@sedlak.dev 2024-03-07T18:06:09+00:00 urn:sha1:58f6aaa710916865253482ff99ef9c87e52d763a 2024-03-09T15:21:16+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-09T15:21:16+00:00 urn:sha1:985befe036f84d1df43dac66e0e78d2e0ec083b2 Eagerly translate `HelpUseLatestEdition` in parser diagnostics Fixes #122130. This makes me suspicious of these other two usage of `add_to_diagnostic()`. Would they *also* crash? I haven't attempted to construct test cases for them. ``` compiler/rustc_parse/src/parser/expr.rs 3453: errors::HelpUseLatestEdition::new().add_to_diagnostic(e); compiler/rustc_hir_typeck/src/expr.rs 2603: HelpUseLatestEdition::new().add_to_diagnostic(&mut err); ``` This also seems like a footgun? 2024-03-07T23:03:42+00:00 许杰友 Jieyou Xu (Joe) jieyouxu@outlook.com 2024-03-07T23:03:42+00:00 urn:sha1:4663fbb2cb6922c28c4bd4e4947d8213f00382b3 2024-03-07T17:32:47+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2024-03-07T17:32:47+00:00 urn:sha1:2e3bde2bc4569150753feb477b5665330cfd480e AST validation: Improve handling of inherent impls nested within functions and anon consts Minimal fix for issue #121607 extracted from PR #120698 for ease of backporting and since I'd like to improve PR #120698 in such a way that it makes AST validator truly robust against such sort of regressions (AST validator is generally *beyond* footgun-y atm). The current version of PR #120698 sort of does that already but there's still room for improvement. Fixes #89342. Fixes [after beta-backport] #121607. Partially addresses #119924 (#120698 aims to fully fix it). --- ### Explainer The last commit of PR #119505 regressed issue #121607. Previously we would reject visibilities on associated items with `visibility_not_permitted` if we were in a trait (by checking the parameter `ctxt` of `visit_assoc_item` which was 100% accurate) or if we were in a trait impl (by checking a flag called `in_trait_impl` tracked in `AstValidator` which was/is only accurate if the visitor methods correctly updated it which isn't actually the case giving rise to the old open issue #89342). In PR #119505, I moved even more state into the `AstValidator` by generalizing the flag `in_trait_impl` to `trait_or_trait_impl` to be able to report more precise diagnostics (modeling *Trait | TraitImpl*). However since we/I didn't update `trait_or_trait_impl` in all places to reflect reality (similar to us not updating `in_trait_impl` before), this lead to https://github.com/rust-lang/rust/issues/121607#issuecomment-1963084636 getting wrongfully rejected. Since PR #119505 we reject visibilities if the “globally tracked” (wrt. to `AstValidator`) `outer_trait_or_trait_impl` is `Some`. Crucially, when visiting an inherent impl, I never reset `outer_trait_or_trait_impl` back to `None` leading us to believe that `bar` in the stack [`trait Foo` > `fn foo` > `impl Bar` > `pub fn bar`] (from the MCVE) was an inherent associated item (we saw `trait Foo` but not `impl Bar` before it). The old open issue #89342 is caused by the aforementioned issue of us never updating `in_trait_impl` prior to my PR #119505 / `outer_trait_or_trait` after my PR. Stack: [`impl Default for Foo` > `{` > `impl Foo` > `pub const X`] (we only saw `impl Default for Foo` but not the `impl Foo` before it). --- This PR is only meant to be a *hot fix*. I plan on completely *rewriting* `AstValidator` from the ground up to not rely on “globally tracked” state like this or at least make it close to impossible to forget updating it when descending into nested items (etc.). Other visitors do a way better job at that (e.g. AST lowering). I actually plan on experimenting with moving more and more logic from `AstValidator` into the AST lowering pass/stage/visitor to follow the [Parse, don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) “pattern”. --- r? `@compiler-errors` 2024-03-07T14:07:08+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2024-03-07T14:07:08+00:00 urn:sha1:9bda4e47c7f12c0aaadfc7bc12cc486c4e456418 Cancel parsing ever made during recovery Fixes #122112 It would be nice if diagnostics from recovery were automatically cancelled... 🤔 2024-03-07T06:27:09+00:00 Oli Scherer git-spam-no-reply9815368754983@oli-obk.de 2024-02-15T17:12:05+00:00 urn:sha1:8206cffc48b77886e18ecdf22e8762aaaa792eec 2024-03-06T21:59:03+00:00 clubby789 jamie@hill-daniel.co.uk 2024-03-06T21:59:03+00:00 urn:sha1:8e45d0fe495358bbb2415f1c0eec92d28b50c743