Subtree update of rust-analyzer
#120447
Subtree update of rust-analyzer
#120447
Conversation
By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars. NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together. One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error.
Starting from cargo#13311, Cargo's compiler artifact message uses Package ID specification as package's identifier format.
…etrochenkov Detect `NulInCStr` error earlier. By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars. NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together. One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error. r? ```@fee1-dead```
…acrum fix(rust-analyzer): use new pkgid spec to compare Starting from rust-lang/cargo#13311, Cargo's compiler artifact message uses Package ID specification as package's identifier format. Zulip topic: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/proc-macro-test.20bootstrap.20and.20pkgid.20JSON cc `@ehuss`
Remove unused codes Detected by rust-lang#118257
This reverts commit 6001c50.
internal: Sync from downstream
Currently there is no proper way to get a target FileRange for a given Definition.
…is, r=Veykril Use upstream exhaustiveness checker! Because it has been librarified! The extra `Apache-2.0 WITH LLVM-exception` license is for `rustc_apfloat`. Also this duplicates `rustc_index` because the other upstream deps are still on an earlier version. They should be bumpable now though. Good thing is that we don't need this new crate to be synchronized with the others, which will make our lives easier.
This reverts commit 0ea0565.
minor: Bump rustc crates This also reverts the earlier revert.
…Veykril internal: Make TryToNav trait public Currently there is no proper way to get a target FileRange for a given Definition.
…acro, r=Veykril Replaced adjusted_display_range with adjusted_display_range_new in mismatched_arg_count For detailed description - see related issue. Fixes: rust-lang#16407
Oh, I thought the CCed people would look at it.
We do it every week(-ish) as well, but recently ran into a lot of bootstrap and lint related issues, like the "unknown The other thing is that We were also stopping merges on the rust-analyzer side until the sync back (rust -> rust-analyzer), because if the rust-analyzer repository changed, we'd get more conflicts. What helped here was doing the sync back only up to the release commit, not up to master. So instead of:
This works much better:
We always sync both ways, not only when it stops building, because of rust-lang/rust-analyzer#13676. I think you're using |
|
Ouch. :( Okay that sounds quite painful. Not sure why it's so much worse for RA than for Miri. Do you have a lot of conflicts? We do syncs in the two directions largely independent of each other and that works fine; that seems to be a subtree vs josh-proxy issue. But if the "sync both ways" can be automated that should not in itself be such a big deal I would expect. But maybe I am underestimating this, having to coordinate multiple branches does sound like significant overhead. The git master version of josh is pretty reliable, yeah. (The latest released version still has an issue that can sometimes be blocking.) Happy to talk more if you want to explore switching RA to josh (but probably best to start a new thread e.g. on Zulip of that rather than discussing it here). |
We used to freeze |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (bf3c6c5): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 662.648s -> 662.752s (0.02%) |
|
@mu001999 was this in time for you? Guess not, sorry 😔. |
Never mind ;) seems the CI stuck again unexpectedly |
r? ghost