Move collections from libextra into libcollections #12010
Conversation
src/libarena/lib.rs Outdated
There was a problem hiding this comment.
I think that this extra dependency could actually be removed now?
| Maybe the |
| I think that this is a great crate to have. The "collections library" is quite a meaty crate that I imagine will be quite useful to downstream users. I do have some concerns about this though:
|
| Man fixing things up is annoying. Just when I think I'm done, I find that now I need to fix up the documentation, which means rebuilding the whole thing over again. I think I've fixed everything now. I just haven't rebuilt to run the documentation tests. |
| Anyway, I've fixed up the things you guys mentioned.
Everything should be working now. |
src/doc/index.md Outdated
There was a problem hiding this comment.
Needs backticks (), and maybe "The collectionslibrary of generic data-structures" or even just "Thecollections` library"? (Repeating "collection" twice seems a little peculiar.)
There was a problem hiding this comment.
Yeah, I was unsure what to put there.
| Ran all the tests after a bit of doc editing and everything works fine. |
src/doc/rust.md Outdated
There was a problem hiding this comment.
Let's leave this example as extra for now.
There was a problem hiding this comment.
It was an unfortunate collision. I'll change it to extra::time instead.
| @alexcrichton: It doesn't seem to automatically inject |
| Ah, nevermind then! I guess perhaps there's a test that uses something from |
| The benchmarks need |
| I've rebased it against master, and all the tests ran fine. Now that the other major changes are done (libsync and libserialize), unless there's something else you want, it's ready for merge. |
| Oops. Forgot to add the fixes for a few tests. Now it's ready. |
| @alexcrichton: I've rebased it. (Was the failure above a fault on my part?) |
| The previous assertion is a bit disturbing, but we'll see what bors has to say this time around. |
| What the heck is happening? The log says the test failed because of "unresolved import. maybe a missing I'm confused. |
| the |
| Good to know it wasn't my fault. :) I'll get to fixing it now. (and any other tests that will have the same problem) |
| Fixed. This time I ran |
Part of #8784 Changes: - Everything labeled under collections in libextra has been moved into a new crate 'libcollection'. - Renamed container.rs to deque.rs, since it was no longer 'container traits for extra', just a deque trait. - Crates that depend on the collections have been updated and dependencies sorted. - I think I changed all the imports in the tests to make sure it works. I'm not entirely sure, as near the end of the tests there was yet another `use` that I forgot to change, and when I went to try again, it started rebuilding everything, which I don't currently have time for. There will probably be incompatibility between this and the other pull requests that are splitting up libextra. I'm happy to rebase once those have been merged. The tests I didn't get to run should pass. But I can redo them another time if they don't.
Config revamp Fixes rust-lang/rust-analyzer#11790 Fixes rust-lang/rust-analyzer#12115 This PR changes a lot of config names, and a few ones are being merged or split apart. The reason for this is that our configuration names currently are rather inconsistent and some where poorly chosen in regards to extensability. This PR plans to fix that. We still allow the old config names by patching them to the new ones before deserializing to keep backwards compatability with other clients (the VSCode client will auto update the config) but ideally we will get rid of that layer in the future. Here is a list of the changes: These are simple renames `old_name | alias1 | alias2 ... -> new_name` (the vscode client will fix these up automagically): ``` assist_allowMergingIntoGlobImports -> imports_merge_glob assist_exprFillDefault -> assist_expressionFillDefault assist_importEnforceGranularity -> imports_granularity_enforce assist_importGranularity | assist_importMergeBehavior | assist_importMergeBehaviour -> imports_granularity_group assist_importGroup -> imports_group_enable assist_importPrefix -> imports_prefix cache_warmup -> primeCaches_enable cargo_loadOutDirsFromCheck -> cargo_buildScripts_enable cargo_runBuildScripts | cargo_runBuildScriptsCommand -> cargo_runBuildScripts_overrideCommand cargo_useRustcWrapperForBuildScripts -> cargo_runBuildScripts_useRustcWrapper completion_snippets -> completion_snippets_custom diagnostics_enableExperimental -> diagnostics_experimental_enable experimental_procAttrMacros -> procMacro_attributes_enable highlighting_strings -> semanticHighlighting_strings_enable highlightRelated_breakPoints -> semanticHighlighting_breakPoints_enable highlightRelated_exitPoints -> semanticHighlighting_exitPoints_enable highlightRelated_yieldPoints -> semanticHighlighting_yieldPoints_enable highlightRelated_references -> semanticHighlighting_references_enable hover_documentation -> hover_documentation_enable hover_linksInHover | hoverActions_linksInHover -> hover_links_enable hoverActions_debug -> hoverActions_debug_enable hoverActions_enable -> hoverActions_enable_enable hoverActions_gotoTypeDef -> hoverActions_gotoTypeDef_enable hoverActions_implementations -> hoverActions_implementations_enable hoverActions_references -> hoverActions_references_enable hoverActions_run -> hoverActions_run_enable inlayHints_chainingHints -> inlayHints_chainingHints_enable inlayHints_closureReturnTypeHints -> inlayHints_closureReturnTypeHints_enable inlayHints_hideNamedConstructorHints -> inlayHints_typeHints_hideNamedConstructorHints inlayHints_parameterHints -> inlayHints_parameterHints_enable inlayHints_reborrowHints -> inlayHints_reborrowHints_enable inlayHints_typeHints -> inlayHints_typeHints_enable lruCapacity -> lru_capacity runnables_cargoExtraArgs -> runnables_extraArgs runnables_overrideCargo -> runnables_command rustcSource -> rustc_source rustfmt_enableRangeFormatting -> rustfmt_rangeFormatting_enable ``` These are configs that have been merged or split apart, which have to be manually updated by the user: ``` callInfo_full -> signatureInfo_detail, signatureInfo_documentation_enable cargo_allFeatures, cargo_features -> cargo_features checkOnSave_allFeatures, checkOnSave_features -> checkOnSave_features completion_addCallArgumentSnippets completion_addCallParenthesis -> completion_callable_snippets ```
…-keys, r=Veykril Fix obsolete config keys The config keys were drastically reorganized by rust-lang#12010, but the docs don't reflect the updates, causing inconsistency and confusion. I checked for such obsolete configuration keys and updated to the new one. For reproducibility, I attach a small shell script that I used to examine the old keys. Now the script only detects `cargoExtraArgs` and `overrideCargo`, which originates from other type definition in the code but not from the configuration. <details><summary>script</summary> ```bash echo "allowMergingIntoGlobImports exprFillDefault importEnforceGranularity importGranularity importMergeBehavior importMergeBehaviour importGroup importPrefix warmup loadOutDirsFromCheck runBuildScripts runBuildScriptsCommand useRustcWrapperForBuildScripts enableExperimental procAttrMacros breakPoints exitPoints yieldPoints linksInHover linksInHover gotoTypeDef chainingHints closureReturnTypeHints hideNamedConstructorHints parameterHints reborrowHints typeHints lruCapacity cargoExtraArgs overrideCargo rustcSource enableRangeFormatting assist\.allowMergingIntoGlobImports assist\.exprFillDefault assist\.importEnforceGranularity assist\.importGranularity assist\.importMergeBehavior assist\.importMergeBehaviour assist\.importGroup assist\.importPrefix primeCaches\.enable cache\.warmup cargo\.loadOutDirsFromCheck cargo\.runBuildScripts cargo\.runBuildScriptsCommand cargo\.useRustcWrapperForBuildScripts completion\.snippets diagnostics\.enableExperimental experimental\.procAttrMacros highlighting\.strings highlightRelated\.breakPoints highlightRelated\.exitPoints highlightRelated\.yieldPoints highlightRelated\.references hover\.documentation hover\.linksInHover hoverActions\.linksInHover hoverActions\.debug hoverActions\.enable hoverActions\.gotoTypeDef hoverActions\.implementations hoverActions\.references hoverActions\.run inlayHints\.chainingHints inlayHints\.closureReturnTypeHints inlayHints\.hideNamedConstructorHints inlayHints\.parameterHints inlayHints\.reborrowHints inlayHints\.typeHints lruCapacity runnables\.cargoExtraArgs runnables\.overrideCargo rustcSource rustfmt\.enableRangeFormatting allFeatures addCallArgumentSnippets addCallParenthesis callInfo\.full cargo\.allFeatures checkOnSave\.allFeatures completion\.addCallArgumentSnippets completion\.addCallParenthesis" | while read -r pattern do rg '\b'$pattern'\b([^.]|$)' . -g "!crates/rust-analyzer/src/config/patch_old_style.rs" -g "!editors/code/src/config.ts" -g "!a.sh" --no-heading --color=always --line-number done exit excluded # debug # enable # run # implementations # references # documentation # references # snippets # strings # full ``` </details>
…ng-for-multi-dimension-arrays, r=Alexendoo fix: `manual_memcpy` wrong indexing for multi dimensional arrays fixes: rust-lang#9334 This PR fixes an invalid suggestion for multi-dimensional arrays. For example, ```rust let src = vec![vec![0; 5]; 5]; let mut dst = vec![0; 5]; for i in 0..5 { dst[i] = src[i][i]; } ``` For the above code, Clippy suggests `dst.copy_from_slice(&src[i]);`, but it is not compilable because `i` is only used to loop the array. I adjusted it so that Clippy `manual_memcpy` works properly for multi-dimensional arrays. changelog: [`manual_memcpy`]: Fixes invalid indexing suggestions for multi-dimensional arrays
4 participants
Part of #8784
Changes:
usethat I forgot to change, and when I went to try again, it started rebuilding everything, which I don't currently have time for.There will probably be incompatibility between this and the other pull requests that are splitting up libextra. I'm happy to rebase once those have been merged.
The tests I didn't get to run should pass. But I can redo them another time if they don't.