about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2023-02-21Auto merge of #107728 - RalfJung:miri-dyn-star, r=RalfJung,oli-obkbors-85/+320
Miri: basic dyn* support As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something. TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all. Strangely I did not need to do the equivalent of [this diff](https://github.com/rust-lang/rust/pull/106532#discussion_r1087095963) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized! r? `@oli-obk` Cc `@eholk` (dyn-star) https://github.com/rust-lang/rust/issues/102425
2023-02-21Auto merge of #105462 - oli-obk:feeding_full, r=cjgillot,petrochenkovbors-453/+480
give the resolver access to TyCtxt The resolver is now created after TyCtxt is created. Then macro expansion and name resolution are run and the results fed into queries just like before this PR. Since the resolver had (before this PR) mutable access to the `CStore` and the source span table, these two datastructures are now behind a `RwLock`. To ensure that these are not mutated anymore after the resolver is done, a read lock to them is leaked right after the resolver finishes. ### PRs split out of this one and leading up to it: * https://github.com/rust-lang/rust/pull/105423 * https://github.com/rust-lang/rust/pull/105357 * https://github.com/rust-lang/rust/pull/105603 * https://github.com/rust-lang/rust/pull/106776 * https://github.com/rust-lang/rust/pull/106810 * https://github.com/rust-lang/rust/pull/106812 * https://github.com/rust-lang/rust/pull/108032
2023-02-20Auto merge of #108286 - matthiaskrgr:rollup-dwy99rf, r=matthiaskrgrbors-133/+499
Rollup of 6 pull requests Successful merges: - #108241 (Fix handling of reexported macro in doc hidden items) - #108254 (Refine error span for trait error into borrowed expression) - #108255 (Remove old FIXMEs referring to #19596) - #108257 (Remove old FIXME that no longer applies) - #108276 (small `opaque_type_origin` cleanup) - #108279 (Use named arguments for `{,u}int_impls` macro) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-02-20Rollup merge of #108279 - Nilstrieb:int, r=scottmcmMatthias Krüger-78/+356
Use named arguments for `{,u}int_impls` macro This makes it way easier to understand. r? `@scottmcm`
2023-02-20Rollup merge of #108276 - lcnr:opaque-tys, r=oli-obkMatthias Krüger-26/+18
small `opaque_type_origin` cleanup r? `@oli-obk`
2023-02-20Rollup merge of #108257 - fee1-dead-contrib:fixme-1, r=tmiaskoMatthias Krüger-5/+0
Remove old FIXME that no longer applies it looks like Encodable was fallible at some point, but that was changed which means that this FIXME is no longer applicable
2023-02-20Rollup merge of #108255 - fee1-dead-contrib:fix-old-fixme, r=cjgillotMatthias Krüger-3/+0
Remove old FIXMEs referring to #19596 Having an inner function that accepts a mutable reference seems to be the only way this can be expressed. Taking a mutable reference would call the same function with a new type &mut F which then causes the infinite recursion error in #19596.
2023-02-20Rollup merge of #108254 - Nathan-Fenner:nathanf/error-span-ref-trait-refine, ↵Matthias Krüger-16/+67
r=WaffleLapkin Refine error span for trait error into borrowed expression Extends the error span refinement in #106477 to drill into borrowed expressions just like tuples/struct/enum literals. For example, ```rs trait Fancy {} trait Good {} impl <'a, T> Fancy for &'a T where T: Good {} impl <S> Good for Option<S> where S: 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 } ``` Existing heuristics try to find the right part of the expression to "point at"; current heuristics look at e.g. struct constructors and tuples. This PR adds a new check for borrowed expressions when looking into a borrowed type.
2023-02-20Rollup merge of #108241 - GuillaumeGomez:fix-reexported-macro-handling, ↵Matthias Krüger-5/+58
r=notriddle Fix handling of reexported macro in doc hidden items Fixes https://github.com/rust-lang/rust/issues/108231. Fixes #59368. r? `@notriddle`
2023-02-20Add test for reexported hidden macroGuillaume Gomez-0/+22
2023-02-20Add regression test for #108231Guillaume Gomez-0/+23
2023-02-20Fix handling of reexported macro in doc hidden itemsGuillaume Gomez-5/+13
2023-02-20Auto merge of #108260 - lnicola:rust-analyzer-2023-02-20, r=lnicolabors-942/+1800
:arrow_up: rust-analyzer r? `@ghost`
2023-02-20Use named arguments for `int_impl` macroNilstrieb-39/+182
This makes it easier to understand.
2023-02-20Use named arguments for `uint_impl` macroNilstrieb-39/+174
This makes it easier to understand.
2023-02-20small `opaque_type_origin` cleanuplcnr-26/+18
2023-02-20Auto merge of #108268 - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgrbors-325/+506
Rollup of 5 pull requests Successful merges: - #108124 (Document that CStr::as_ptr returns a type alias) - #108171 (Improve building compiler artifacts output) - #108200 (Use restricted Damerau-Levenshtein distance for diagnostics) - #108259 (remove FIXME that doesn't require fixing) - #108265 ("`const` generic" -> "const parameter") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-02-20Remove `ResolverTree`Oli Scherer-25/+4
2023-02-20Remove IntoDefIdTreeOli Scherer-29/+15
2023-02-20Remove some unnecessary tcx-passingOli Scherer-7/+8
2023-02-20Stop passing in values that one can also get from the tcx lazilyOli Scherer-34/+23
2023-02-20Move the resolver into a queryOli Scherer-31/+54
2023-02-20Make `configure_and_expand` "infalllible" by just aborting the compilation ↵Oli Scherer-37/+33
if it fails instead of bubbling out an error
2023-02-20Use tcx queries instead of passing the values to `configure_and_expand`.Oli Scherer-13/+8
2023-02-20Remove definitions field that is only needed for one methodOli Scherer-14/+8
2023-02-20Stuff a TyCtxt into the ResolverOli Scherer-41/+32
2023-02-20Remove a redundant function argumentOli Scherer-10/+3
2023-02-20Run the resolver after TyCtxt constructionOli Scherer-57/+69
2023-02-20Make untracked.source_span lockable so that resolution can still write to it ↵Oli Scherer-12/+12
when using TyCtxt
2023-02-20Make untracked.cstore lockable so that resolution can still write to it when ↵Oli Scherer-36/+50
using TyCtxt
2023-02-20Revert most of the custom place computation, it was unnecessary.Oli Scherer-15/+10
2023-02-20Remove commented out codeOli Scherer-2/+0
2023-02-20Deduplicate some logic between dyn* and dynOli Scherer-46/+37
2023-02-20fix Stacked Borrows interaction with dyn*Ralf Jung-2/+4
2023-02-20slightly beef up dyn-star-to-dyn testRalf Jung-3/+11
2023-02-20basic dyn* support for MiriRalf Jung-84/+325
2023-02-20Rollup merge of #108265 - lcnr:cg-error-msg, r=BoxyUwUMatthias Krüger-12/+9
"`const` generic" -> "const parameter"
2023-02-20Rollup merge of #108259 - fee1-dead-contrib:fixme-2, r=TaKO8KiMatthias Krüger-3/+3
remove FIXME that doesn't require fixing
2023-02-20Rollup merge of #108200 - jhpratt:restricted-damerau-levenshtein-distance, ↵Matthias Krüger-271/+357
r=tmiasko Use restricted Damerau-Levenshtein distance for diagnostics This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a _restricted_ implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account. This was first brought up [on IRLO](https://internals.rust-lang.org/t/18227) when it was noticed that the diagnostic for `prinltn!` (transposed L and T) was `print!` and not `println!`. Only a single existing UI test was effected, with the result being an objective improvement. ~~I have left the method name and various other references to the Levenshtein algorithm untouched, as the exact manner in which the edit distance is calculated should not be relevant to the caller.~~ r? ``@estebank`` ``@rustbot`` label +A-diagnostics +C-enhancement
2023-02-20Rollup merge of #108171 - mattjperez:compiler-artifacts-output, r=jyn514Matthias Krüger-39/+132
Improve building compiler artifacts output Fixes #108051 ``@Manishearth,`` ``@jyn514`` mentioned you might be interested in these changes to the outputs.
2023-02-20Rollup merge of #108124 - kornelski:cstr_c_char, r=thomccMatthias Krüger-0/+5
Document that CStr::as_ptr returns a type alias Rustdoc resolves type aliases too eagerly #15823 which makes the [std re-export](https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#method.as_ptr) of `CStr::as_ptr` show `i8` instead of `c_char`. To work around this I've added info about `c_char` in the method's description. BTW, I've also added a comment to what-not-to-do example in case someone copypasted it without reading the surrounding text.
2023-02-20Auto merge of #107721 - megakorre:issue_105700, r=petrochenkovbors-0/+24
create dummy placeholder crate to prevent compiler from panicing This PR is to address the panic found in https://github.com/rust-lang/rust/issues/105700. There are 2 separate things going on with this panic. First the code could not generate a dummy response for crate fragment types when it hits the recursion limit. This PR adds the method to the trait implementation for `DymmyResult` to be able to create a dummy crate node. This stops the panic from happening. The second thing that is not addressed (and maybe does not need addressing? 🤷🏻) is that when you have multiple attributes it ends up treating attributes that follow another as being the result of expanding the former (maybe there is a better way to say that). So you end up hitting the recursion limit. Even though you would think there is no expansion happening here. If you did not hit the recursion limit the compiler would output that `invalid_attribute` does not exists. But it currently exits before the resolution step when the recursion limit is reached here.
2023-02-20`const` generic -> const parameter in err msglcnr-12/+9
2023-02-20Prepare crate loader for LockGuardOli Scherer-10/+11
2023-02-20Prepare for adding a `TyCtxt` to `Resolver`Oli Scherer-194/+247
2023-02-20Auto merge of #107969 - b-naber:proj-relate-variance, r=lcnrbors-4/+159
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes https://github.com/rust-lang/rust/issues/96514 Supersedes https://github.com/rust-lang/rust/pull/105958 r? `@lcnr`
2023-02-20create dummy placeholder crate to prevent compilerPatrik Kårlin-0/+24
2023-02-20:arrow_up: rust-analyzerLaurențiu Nicola-942/+1800
2023-02-20Auto merge of #106316 - camelid:rustdoc-all-only-stable, r=GuillaumeGomezbors-20/+45
Only include stable lints in `rustdoc::all` group Fixes #106289. Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway. r? `@GuillaumeGomez`
2023-02-20remove FIXME that doesn't require fixingDeadbeef-3/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 07:37:19 +0000