Rollup of 10 pull requests #129770
Closed
Rollup of 10 pull requests #129770
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
Add an explanatory sentence and some sample code to help readers understand why this struct exists.
minor: Add a doc comment for OpQueue Add an explanatory sentence and some sample code to help readers understand why this struct exists.
…ebold internal: Be more resilient to bad language item definitions in binop inference Fixes rust-lang#16287 Fixes rust-lang#16286 There's one more in `write_fn_trait_method_resolution`, but I'm not sure if it won't cause further problems in `infer_closures`.
fix: Panic while canonicalizing erroneous projection type Fixes rust-lang#17866 The root cause of rust-lang#17866 is quite horrifyng 😨 ```rust trait T { type A; } type Foo = <S as T>::A; // note that S isn't defined fn main() { Foo {} } ``` While inferencing alias type `Foo = <S as T>::A`; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer.rs#L1388-L1398 the error type `S` in it is substituted by inference var in L1396 above as below; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L866-L869 This new inference var's index is `1`, as the type inferecing procedure here previously inserted another inference var into same `InferenceTable`. But after that, the projection type made from the above then passed to the following function; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/traits.rs#L88-L96 here, a whole new `InferenceTable` is made, without any inference var and in the L94, this table calls; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L364-L370 And while registering `AliasEq` `obligation`, this obligation contains inference var `?1` made from the previous table, but this table has only one inference var `?0` made at L365. So, the chalk panics when we try to canonicalize that obligation to register it, because the obligation contains an inference var `?1` that the canonicalizing table doesn't have. Currently, we are calling `InferenceTable::new()` to do some normalizing, unifying or coercing things to some targets that might contain inference var that the new table doesn't have. I think that this is quite dangerous footgun because the inference var is just an index that does not contain the information which table does it made from, so sometimes this "foreign" index might cause panic like this case, or point at the wrong variable. This PR mitigates such behaviour simply by inserting sufficient number of inference vars to new table to avoid such problem. This strategy doesn't harm current r-a's intention because the inference vars that passed into new tables are just "unresolved" variables in current r-a, so this is just making sure that such "unresolved" variables exist in the new table
fix: Panic while hovering associated function with type annotation on generic param that not inherited from its container type Fixes rust-lang#17871 We call `generic_args_sans_defaults` here; https://github.com/rust-lang/rust-analyzer/blob/64a140527b383e3a2fe95908881624fc5374c60c/crates/hir-ty/src/display.rs#L1021-L1034 but the following substitution inside that function panic in rust-lang#17871; https://github.com/rust-lang/rust-analyzer/blob/64a140527b383e3a2fe95908881624fc5374c60c/crates/hir-ty/src/display.rs#L1468 it's because the `Binders.binder` inside `default_parameters` has a same length with the generics of the function we are hovering on, but the generics of it is split into two, `fn_params` and `parent_params`. Because of this, it may panic if the function has one or more default parameters and both `fn_params` and `parent_params` are non-empty, like the case in the title of this PR. So, we must call `generic_args_sans_default` first and then split it into `fn_params` and `parent_params`
…kril internal: Properly check the edition for edition dependent syntax kinds This puts the current edition in a bunch of places, most of which I annoted with FIXMEs asside from the ones in ide-assists because I couldnt bother with those
Assuming it isn't cancelled. Closes rust-lang#17902. The only place CommandHandle::join is used is when the flycheck command finishes, so this commit changes the behavior of the method itself.
…zyCell/Lock This doesn't get rid of the once_cell dependency, unfortunately, since we have dependencies that use it, but it's a nice to do cleanup. And when our deps will eventually get rid of once_cell we will get rid of it for free.
This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison). Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!).
internal: Replace once_cell with std's recently stabilized OnceCell/Lock and LazyCell/Lock This doesn't get rid of the once_cell dependency, unfortunately, since we have dependencies that use it, but it's a nice to do cleanup. And when our deps will eventually get rid of once_cell we will get rid of it for free.
…s, r=Veykril Test for word boundary in `FindUsages` This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison). Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!). Feel free to close this if you consider this a non-issue, as most short identifiers are local.
Allow flycheck process to exit gracefully Assuming it isn't cancelled. Closes rust-lang#17902. The only place CommandHandle::join() is used is when the flycheck command finishes, so this commit changes the behavior of the method itself. The only reason I can see for the existing behavior is if the command is somehow holding onto a build lock longer than it should, this would force it to be released. But it would be a pretty heavy-handed way to solve that issue. I'm not aware of this occurring in practice.
Implement lifetime inferring
This PR touches a lot of parts. But the main changes are changing `hir_expand::Name` to be raw edition-dependently and only when necessary (unrelated to how the user originally wrote the identifier), and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware (this was done in rust-lang#17896, but the FIXMEs were fixed here). It is possible that I missed some cases, but most IDE parts should properly escape (or not escape) identifiers now. The rules of thumb are: - If we show the identifier to the user, its rawness should be determined by the edition of the edited crate. This is nice for IDE features, but really important for changes we insert to the source code. - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update tests when an edition becomes stable, to avoid churn). - For debugging tools (helper methods and logs), I used `Edition::LATEST`.
…-keyword, r=Veykril fix: Properly account for editions in names This PR touches a lot of parts. But the main changes are changing `hir_expand::Name` to be raw edition-dependently and only when necessary (unrelated to how the user originally wrote the identifier), and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware (this was done in rust-lang#17896, but the FIXMEs were fixed here). It is possible that I missed some cases, but most IDE parts should properly escape (or not escape) identifiers now. The rules of thumb are: - If we show the identifier to the user, its rawness should be determined by the edition of the edited crate. This is nice for IDE features, but really important for changes we insert to the source code. - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update tests when an edition becomes stable, to avoid churn). - For debugging tools (helper methods and logs), I used `Edition::LATEST`. Reviewing notes: This is a really big PR but most of it is mechanical translation. I changed `Name` displayers to require an edition, and followed the compiler errors. Most methods just propagate the edition requirement. The interesting cases are mostly in `ide-assists`, as sometimes the correct crate to fetch the edition from requires awareness (there may be two). `ide-completions` and `ide-diagnostics` were solved pretty easily by introducing an edition field to their context. `ide` contains many features, for most of them it was propagated to the top level function and there the edition was fetched based on the file. I also fixed all FIXMEs from rust-lang#17896. Some required introducing an edition parameter (usually not for many methods after the changes to `Name`), some were changed to a new method `is_any_identifier()` because they really want any possible keyword. Fixes rust-lang#17895. Fixes rust-lang#17774.
…r=davidbarsky Add scip/lsif flag to exclude vendored libaries rust-lang#17809 changed StaticIndex to include vendored libraries. This PR adds a flag to disable that behavior. At work, our monorepo has too many rust targets to index all at once, so we split them up into several shards. Since all of our libraries are vendored, if rust-analyzer includes them, sharding no longer has much benefit, because every shard will have to index the entire transitive dependency graphs of all of its targets. We get around the issue presented in rust-lang#17809 because some other shard will index the libraries directly.
…, r=lnicola Remove rust-analyzer.workspace.discoverProjectRunner The functionality for this vscode config option was removed in rust-lang#17395, so it doesn't do anything anymore.
Pin `rowan` to `0.15.15` To prevent rust-lang#17914, I think that it would be safer pinning this before we fix it correctly
add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le This backports the QNX 7.1 aarch64 implementation to 7.0. * [x] required `-lregex` disabled, see rust-lang/libc#3775 (released in libc 0.2.156) * [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s) * [x] a fix in `backtrace` crate to support stack traces rust-lang/backtrace-rs#648 This PR bumps libc dependency to 0.2.158 CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric` # Compile target ```bash # Configure qcc build environment source _path_/_to_/qnx7.0/qnxsdp-env.sh # Tell rust to use qcc when building QNX 7.0 targets export build_env=' CC_aarch64-unknown-nto-qnx700=qcc CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx CXX_aarch64-unknown-nto-qnx700=qcc AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar' # Build rust compiler, libs, and the remote test server env $build_env ./x.py build \ --target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \ rustc library/core library/alloc library/std src/tools/remote-test-server rustup toolchain link stage1 build/host/stage1 ``` # Compile "hello world" ```bash source _path_/_to_/qnx7.0/qnxsdp-env.sh cargo new hello_world cd hello_world cargo +stage1 build --release --target aarch64-unknown-nto-qnx700 ``` # Configure a remote for testing Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues, and found some workarounds. * Temporary dir might not work properly * Default `remote-test-server` has issues binding to an address ``` # ./remote-test-server starting test server thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29: called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly. ```bash # Copy remote-test-server to remote device. You may need to use sftp instead. # ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server qnxdevice:/path/ # Run ssh with port forwarding - so that rust tester can connect to the local port instead ssh -L 12345:127.0.0.1:12345 qnxdevice # on the device, run rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345 ``` # Run test suit Assume all previous environment variables are still set, or re-init them ```bash export TEST_DEVICE_ADDR="localhost:12345" # tidy needs to be skipped due to using un-published libc dependency export exclude_tests=' --exclude src/bootstrap --exclude src/tools/error_index_generator --exclude src/tools/linkchecker --exclude src/tools/tidy --exclude tests/ui-fulldeps --exclude rustc --exclude rustdoc --exclude tests/run-make-fulldeps' env $build_env ./x.py test $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700 ```
…=fmease rustdoc-json: Add test for `Self` type Inspired by rust-lang#128471, the rustdoc-json suite had no tests in place for the `Self` type. This PR adds one. I've also manually checked locally that this test passes on 29e9248, confirming that adding `clean::Type::SelfTy` didn't change the JSON output. (potentially adding a self type to json (insead of (ab)using generic) is tracked in rust-lang#128522) Updates rust-lang#81359 r? ```@fmease```
…b22, r=workingjubilee Bump backtrace to 0.3.74~ish Commit: rust-lang/backtrace-rs@230570f This should help with backtraces on Android, QNX NTO 7.0, and Windows. It addresses a case of backtrace incurring undefined behavior on Android.
…d, r=workingjubilee allow BufReader::peek to be called on unsized types rust-lang#128405
…r=lcnr
Simplify some extern providers
Simplifies some extern crate providers:
1. Generalize the `ProcessQueryValue` identity impl to work on non-`Option` types.
2. Allow `ProcessQueryValue` to wrap its output in an `EarlyBinder`, to simplify `explicit_item_bounds`/`explicit_item_super_predicates`.
3. Use `{ table }` and friends more when possible.
…-dead
Remove `Option<!>` return types.
Several compiler functions have `Option<!>` for their return type. That's odd. The only valid return value is `None`, so why is this type used?
Because it lets you write certain patterns slightly more concisely. E.g. if you have these common patterns:
```
let Some(a) = f() else { return };
let Ok(b) = g() else { return };
```
you can shorten them to these:
```
let a = f()?;
let b = g().ok()?;
```
Huh.
An `Option` return type typically designates success/failure. How should I interpret the type signature of a function that always returns (i.e. doesn't panic), does useful work (modifying `&mut` arguments), and yet only ever fails? This idiom subverts the type system for a cute syntactic trick.
Furthermore, returning `Option<!>` from a function F makes things syntactically more convenient within F, but makes things worse at F's callsites. The callsites can themselves use `?` with F but should not, because they will get an unconditional early return, which is almost certainly not desirable. Instead the return value should be ignored. (Note that some of callsites of `process_operand`, `process_immedate`, `process_assign` actually do use `?`, though the early return doesn't matter in these cases because nothing of significance comes after those calls. Ugh.)
When I first saw this pattern I had no idea how to interpret it, and it took me several minutes of close reading to understand everything I've written above. I even started a Zulip thread about it to make sure I understood it properly. "Save a few characters by introducing types so weird that compiler devs have to discuss it on Zulip" feels like a bad trade-off to me. This commit replaces all the `Option<!>` return values and uses `else`/`return` (or something similar) to replace the relevant `?` uses. The result is slightly more verbose but much easier to understand.
r? `@cjgillot`
…mease Stop using `ty::GenericPredicates` for non-predicates_of queries `GenericPredicates` is a struct of several parts: A list of of an item's own predicates, and a parent def id (and some effects related stuff, but ignore that since it's kinda irrelevant). When instantiating these generic predicates, it calls `predicates_of` on the parent and instantiates its predicates, and appends the item's own instantiated predicates too: https://github.com/rust-lang/rust/blob/acb4e8b6251f1d8da36f08e7a70fa23fc581839e/compiler/rustc_middle/src/ty/generics.rs#L407-L413 Notice how this should result in a recursive set of calls to `predicates_of`... However, `GenericPredicates` is *also* misused by a bunch of *other* queries as a convenient way of passing around a list of predicates. For these queries, we don't ever set the parent def id of the `GenericPredicates`, but if we did, then this would be very easy to mistakenly call `predicates_of` instead of some other intended parent query. Given that footgun, and the fact that we don't ever even *use* the parent def id in the `GenericPredicates` returned from queries like `explicit_super_predicates_of`, It really has no benefit over just returning `&'tcx [(Clause<'tcx>, Span)]`. This PR additionally opts to wrap the results of `EarlyBinder`, as we've tended to use that in the return type of these kinds of queries to properly convey that the user has params to deal with, and it also gives a convenient way of iterating over a slice of things after instantiating.
Subtree update of `rust-analyzer` r? `@ghost`
…r=workingjubilee wasi: Fix sleeping for `Duration::MAX` This commit fixes an assert in the WASI-specific implementation of thread sleep to ensure that sleeping for a very large period of time blocks instead of panicking. This can come up when testing programs that sleep "forever", for example. I'll note that I haven't included a test for this since it's sort of difficult to test. I've tested this locally though that long sleeps do indeed block and short sleeps still only sleep for a short amount of time.
rustbot
added
A-rustdoc-json
|
@bors rollup=never p=10 r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 30, 2024
…kingjubilee Rollup of 10 pull requests Successful merges: - rust-lang#120221 (Don't make statement nonterminals match pattern nonterminals) - rust-lang#127897 (add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le) - rust-lang#129123 (rustdoc-json: Add test for `Self` type) - rust-lang#129642 (Bump backtrace to 0.3.74~ish) - rust-lang#129675 (allow BufReader::peek to be called on unsized types) - rust-lang#129723 (Simplify some extern providers) - rust-lang#129724 (Remove `Option<!>` return types.) - rust-lang#129725 (Stop using `ty::GenericPredicates` for non-predicates_of queries) - rust-lang#129733 (Subtree update of `rust-analyzer`) - rust-lang#129754 (wasi: Fix sleeping for `Duration::MAX`) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
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.
Successful merges:
aarch64_unknown_nto_qnx700target - QNX 7.0 support for aarch64le #127897 (addaarch64_unknown_nto_qnx700target - QNX 7.0 support for aarch64le)Selftype #129123 (rustdoc-json: Add test forSelftype)Option<!>return types. #129724 (RemoveOption<!>return types.)ty::GenericPredicatesfor non-predicates_of queries #129725 (Stop usingty::GenericPredicatesfor non-predicates_of queries)rust-analyzer#129733 (Subtree update ofrust-analyzer)Duration::MAX#129754 (wasi: Fix sleeping forDuration::MAX)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup