-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #124934
Rollup of 5 pull requests #124934
Commits on May 8, 2024
-
Configuration menu - View commit details
-
Copy full SHA for d4c6c77 - Browse repository at this point
Copy the full SHA d4c6c77View commit details
Commits on May 9, 2024
-
Add
ErrorGuaranteed
toRecovered::Yes
and use it more.The starting point for this was identical comments on two different fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`: ``` // FIXME: investigate making this a `Option<ErrorGuaranteed>` recovered: bool ``` I tried that, and then found that I needed to add an `ErrorGuaranteed` to `Recovered::Yes`. Then I ended up using `Recovered` instead of `Option<ErrorGuaranteed>` for these two places and elsewhere, which required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`. This makes things more consistent, because `Recovered` is used in more places, and there are fewer uses of `bool` and `Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible to set `recovered` to `Recovered::Yes` without having emitted an error.
Configuration menu - View commit details
-
Copy full SHA for fd91925 - Browse repository at this point
Copy the full SHA fd91925View commit details -
Configuration menu - View commit details
-
Copy full SHA for 41d36a0 - Browse repository at this point
Copy the full SHA 41d36a0View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3c52553 - Browse repository at this point
Copy the full SHA 3c52553View commit details -
Configuration menu - View commit details
-
Copy full SHA for 5120010 - Browse repository at this point
Copy the full SHA 5120010View commit details -
Rollup merge of rust-lang#124893 - xldenis:public-region-apis, r=lcnr
Make a minimal amount of region APIs public Tools like Creusot, Prusti or Gillian-Rust need to access information about the loans and regions that exist in MIR programs. While `rustc` provides information about loans, there is currently no public way to reason about the regions present in a MIR program. In particular, we to know which regions are actually equal to each other and which ones outlive each other. Currently, `rustc` provides access to `RegionInferenceContext` but the public api hides that last portion of the information. This PR proposes to make a few apis public, allowing verifiers to reason about the lifetimes present in Rust programs: - [eval_equal](https://doc.rust-lang.org/beta/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.eval_equal) - [eval_outlives](https://doc.rust-lang.org/beta/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.eval_outlives) - (Optional) [constraint_sccs](https://doc.rust-lang.org/beta/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.constraint_sccs) The first two functions would allow us to compare regions and from this we can construct the set of `RegionVid` which are actually equal to each other, and then recover the inclusions between those regions, while the second allows for more direct, but _low level_ access to that information.
Configuration menu - View commit details
-
Copy full SHA for ebeedf0 - Browse repository at this point
Copy the full SHA ebeedf0View commit details -
Rollup merge of rust-lang#124919 - nnethercote:Recovered-Yes-ErrorGua…
…ranteed, r=compiler-errors Add `ErrorGuaranteed` to `Recovered::Yes` and use it more. The starting point for this was identical comments on two different fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`: ``` // FIXME: investigate making this a `Option<ErrorGuaranteed>` recovered: bool ``` I tried that, and then found that I needed to add an `ErrorGuaranteed` to `Recovered::Yes`. Then I ended up using `Recovered` instead of `Option<ErrorGuaranteed>` for these two places and elsewhere, which required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`. This makes things more consistent, because `Recovered` is used in more places, and there are fewer uses of `bool` and `Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible to set `recovered` to `Recovered::Yes` without having emitted an error. r? `@oli-obk`
Configuration menu - View commit details
-
Copy full SHA for 0a917f8 - Browse repository at this point
Copy the full SHA 0a917f8View commit details -
Rollup merge of rust-lang#124923 - RalfJung:offset-from-errors, r=com…
…piler-errors interpret/miri: better errors on failing offset_from Fixes rust-lang/miri#3104
Configuration menu - View commit details
-
Copy full SHA for 024881a - Browse repository at this point
Copy the full SHA 024881aView commit details -
Rollup merge of rust-lang#124924 - goofylfg:master, r=est31
chore: remove repetitive words
Configuration menu - View commit details
-
Copy full SHA for a40fa8f - Browse repository at this point
Copy the full SHA a40fa8fView commit details -
Rollup merge of rust-lang#124926 - Alexendoo:feature-maybe-incorrect,…
… r=est31 Make `#![feature]` suggestion MaybeIncorrect Fixes rust-lang/rust-clippy#12784 The `unstable_name_collisions` lint uses `disabled_nightly_features` to mention the feature name, but accepting the suggestion would result in an ambiguity error There are other calls where accepting the feature gate would fix code when ran with `cargo fix --broken-code`, though it's not always desirable to add a feature gate even if the user is currently on nightly so MaybeIncorrect seems appropriate
Configuration menu - View commit details
-
Copy full SHA for 779fe95 - Browse repository at this point
Copy the full SHA 779fe95View commit details