Astconv no mo #12
Closed
Astconv no mo #12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`DiagnosticBuilderInner` was removed some time ago.
- `emitted_at` isn't used outside the crate. - `code` and `messages` are public fields, so there's no point have trivial getters/setters for them. - `suggestions` is public, so the comment about "functionality on `Diagnostic`" isn't needed.
`emit_future_breakage` calls `self.dcx().take_future_breakage_diagnostics()` and then passes the result to `self.dcx().emit_future_breakage_report(diags)`. This commit removes the first of these and lets `emit_future_breakage_report` do the taking. It also inlines and removes what is left of `emit_future_breakage`, which has a single call site.
And make sure all other imports have non-empty resolution lists.
It's only ever used with a reference to `OwnerInfo` as an argument.
internal: Bump release runners to MacOS 12
…-Simulacrum Bump to 1.78 r? `@Mark-Simulacrum`
Co-authored-by: Michael Goulet <michael@errs.io>
add avx512fp16 to x86 target features std_detect avx512fp16: rust-lang/stdarch#1508
…ark-Simulacrum Release notes for 1.76 Cargo, library stabilizations and some cleanups, particularly to future compat, still pending. cc `@cuviper` `@rust-lang/release`
Revert unsound libcore changes fixes rust-lang#120537 these were introduced in rust-lang#119911
coverage: Use normal `edition:` headers in coverage tests Some of these tests were originally written as part of a custom `run-make` test, so at that time they weren't able to use the normal compiletest header directive parser. Now that they're properly integrated, there's no need for them to use `compile-flags` to specify the edition, since they can use `edition` instead. In most cases the `.cov-map` snapshot isn't affected at all, but in a few cases we add or remove a line, which slightly disturbs the first line number in each instrumented function.
…compiler-errors Reconstify `Add` r? project-const-traits I'm not happy with the ui test changes (or failures because I did not bless them and include the diffs in this PR). There is at least some bugs I need to look and try fix: 1. A third duplicated diagnostic when a consumer crate that does not have `effects` enabled has a trait selection error for an upstream const_trait trait. See tests/ui/ufcs/ufcs-qpath-self-mismatch.rs. 2. For some reason, making `Add` a const trait would stop us from suggesting `T: Add` when we try to add two `T`s without that bound. See tests/ui/suggestions/issue-97677.rs
It avoids a lot of repetition.
…ctors, r=dtolnay Make `NonZero` constructors generic. This makes `NonZero` constructors generic, so that `NonZero::new` can be used without turbofish syntax. Tracking issue: rust-lang#120257 ~~I cannot figure out how to make this work with `const` traits. Not sure if I'm using it wrong or whether there's a bug:~~ ```rust 101 | if n == T::ZERO { | ^^^^^^^^^^^^ expected `host`, found `true` | = note: expected constant `host` found constant `true` ``` r? `@dtolnay`
…ebank Stop bailing out from compilation just because there were incoherent traits fixes rust-lang#120343 but also has a lot of "type annotations needed" fallout. Some are fixed in the second commit.
…peof` expression
…as already tainted
…ded-code, r=notriddle Prevent running some code if it is already in the map I realized that a lot of duplicates were being run through this function. Might be better to prevent them from computing all the information if it's already in the cache. r? `@notriddle`
…rors resolve: Unload speculatively resolved crates before freezing cstore Name resolution sometimes loads additional crates to improve diagnostics (e.g. suggest imports). Not all of these diagnostics result in errors, sometimes they are just warnings, like in rust-lang#117772. If additional crates loaded speculatively stay and gets listed by things like `query crates` then they may produce further errors like duplicated lang items, because lang items from speculatively loaded crates are as good as from non-speculatively loaded crates. They can probably do things like adding unintended impls from speculatively loaded crates to method resolution as well. The extra crates will also get into the crate's metadata as legitimate dependencies. In this PR I remove the speculative crates from cstore when name resolution is finished and cstore is frozen. This is better than e.g. filtering away speculative crates in `query crates` because things like `DefId`s referring to these crates and leaking to later compilation stages can produce ICEs much easier, allowing to detect them. The unloading could potentially be skipped if any errors were reported (to allow using `DefId`s from speculatively loaded crates for recovery), but I didn't do it in this PR because I haven't seen such cases of recovery. We can reconsider later if any relevant ICEs are reported. Unblocks rust-lang#117772.
…oli-obk Make it so that async-fn-in-trait is compatible with a concrete future in implementation There's no technical reason why an AFIT like `async fn foo()` cannot be satisfied with an implementation signature like `fn foo() -> Pin<Box<dyn Future<Output = ()> + 'static>>`. We rejected this previously because we were uncertain about how AFITs worked with refinement, but I don't believe this needs to be a restriction any longer. r? oli-obk
…rrors hir: Make sure all `HirId`s have corresponding HIR `Node`s And then remove `tcx.opt_hir_node(hir_id)` in favor of `tcx.hir_node(hir_id)`.
match lowering: consistently lower bindings deepest-first Currently when lowering match expressions to MIR, we do a funny little dance with the order of bindings. I attempt to explain it in the third commit: we handle refutable (i.e. needing a test) patterns differently than irrefutable ones. This leads to inconsistencies, as reported in rust-lang#120210. The reason we need a dance at all is for situations like: ```rust fn foo1(x: NonCopyStruct) { let y @ NonCopyStruct { copy_field: z } = x; // the above should turn into let z = x.copy_field; let y = x; } ``` Here the `y ```````@```````` binding will move out of `x`, so we need to copy the field first. I believe that the inconsistency came about when we fixed rust-lang#69971, and didn't notice that the fix didn't extend to refutable patterns. My guess then is that ordering bindings by "deepest-first, otherwise source order" is a sound choice. This PR implements that (at least I hope, match lowering is hard to follow 🥲). Fixes rust-lang#120210 r? ```````@oli-obk``````` since you merged the original fix to rust-lang#69971 cc ```````@matthewjasper```````
GVN: also turn moves into copies with projections Fixes rust-lang#120613
docs: also check the inline stmt during redundant link check Fixes rust-lang#120444 This issue was brought about by querying `root::webdavfs::A`, a key that doesn't exist in `doc_link_resolutions`. To avoid a panic, I've altered the gating mechanism to allow this lint pass to be skipped. I'm not certain if this is the best solution. An alternative approach might be to leverage other info from the name resolutions instead of `doc_link_resolutions`. After all, all we need is to get the resolution from a combination of `(module, name)`. However, I believe they would yield the same outcome, both skipping this lint.
…ompiler-errors exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered" There was an exception when reporting integer ranges as missing, it's been there for as long as I can remember. This PR removes it. I think it's nicer to report "`0..MAX` not covered" than "`_` not covered". This also makes it consistent with enums, where we report individual enum variants in this case (as showcased in the rest of the `empty-match.rs` test). r? ``@estebank``
…, r=compiler-errors Add `SubdiagnosticMessageOp` as a trait alias. It avoids a lot of repetition. r? matthewjasper
…r-errors
improve pretty printing for associated items in trait objects
* Don't print a binder in front of associated items, because it's not valid syntax.
* e.g. print `dyn for<'a> Trait<'a, Assoc = &'a u8>` instead of `dyn for<'a> Trait<'a, for<'a> Assoc = &'a u8>`.
* Don't print associated items that are implied by a supertrait bound.
* e.g. if we have `trait Sub: Super<Assoc = u8> {}`, then just print `dyn Sub` instead of `dyn Sub<Assoc = u8>`.
I've added the test in the first commit, so you can see the diff of the compiler output in the second commit.
Continue to borrowck even if there were previous errors but only from the perspective of the whole compiler. Individual items should not get borrowcked if their MIR is tainted by errors. r? `@estebank` `@nnethercote`
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#119592 (resolve: Unload speculatively resolved crates before freezing cstore) - rust-lang#120103 (Make it so that async-fn-in-trait is compatible with a concrete future in implementation) - rust-lang#120206 (hir: Make sure all `HirId`s have corresponding HIR `Node`s) - rust-lang#120214 (match lowering: consistently lower bindings deepest-first) - rust-lang#120688 (GVN: also turn moves into copies with projections) - rust-lang#120702 (docs: also check the inline stmt during redundant link check) - rust-lang#120727 (exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered") - rust-lang#120734 (Add `SubdiagnosticMessageOp` as a trait alias.) - rust-lang#120739 (improve pretty printing for associated items in trait objects) r? `@ghost` `@rustbot` modify labels: rollup
Introduce `enter_forall` to supercede `instantiate_binder_with_placeholders` r? `@lcnr` Long term we'd like to experiment with decrementing the universe count after "exiting" binders so that we do not end up creating infer vars in non-root universes even when they logically reside in the root universe. The fact that we dont do this currently results in a number of issues in the new trait solver where we consider goals to be ambiguous because otherwise it would require lowering the universe of an infer var. i.e. the goal `?x.0 eq <T as Trait<?y.1>>::Assoc` where the alias is rigid would not be able to instantiate `?x` with the alias as there would be a universe error. This PR is the first-ish sort of step towards being able to implement this as eventually we would want to decrement the universe in `enter_forall`. Unfortunately its Difficult to actually implement decrementing universes nicely so this is a separate step which moves us closer to the long term goal ✨
fmease
pushed a commit
that referenced
this pull request
Jul 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.