Skip to content

Consolidate codes dealing with LLVM struct type - #5089

Closed
sanxiyn wants to merge 1 commit into
rust-lang:incomingfrom
sanxiyn:llvm-struct
Closed

Consolidate codes dealing with LLVM struct type#5089
sanxiyn wants to merge 1 commit into
rust-lang:incomingfrom
sanxiyn:llvm-struct

Conversation

@sanxiyn

Copy link
Copy Markdown
Contributor

Note on struct_elt: the comment is wrong, it actually dereferences the nth element of LLVM struct type if it is a pointer. That's why T_ptr is removed in callee.rs.

bors added a commit that referenced this pull request Feb 26, 2013
Note on `struct_elt`: the comment is wrong, it actually dereferences the nth element of LLVM struct type if it is a pointer. That's why `T_ptr` is removed in `callee.rs`.
@borsbors closed this Feb 26, 2013
calebcartwright pushed a commit to calebcartwright/rust that referenced this pull request Mar 30, 2022
* Handle non-ascii character at boundary
* Replace substraction underflow check with early termination
RalfJung added a commit to RalfJung/rust that referenced this pull request Jun 12, 2026
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
…t-lang#5186
5089: Disable auto-complete on comments r=matklad a=BGluth
Resolvesrust-lang#4907 by disabling any auto-completion on comments.
As flodiebold [pointed out](rust-lang/rust-analyzer#4907 (comment)), in the future we may want to support some form of auto-completion within doc comments, but for now it was suggested to just disable auto-completion on them entirely.
The implementation involves adding a new field `is_comment` to `CompletionContext` and checking if the immediate token we auto-completed on is a comment. I couldn't see a case where we need to check any of the ancestors, but let me know if this is not sufficient. I also wasn't sure if it was necessary to add a new field to this struct, but I decided it's probably the best option if we want to potentially do auto-completion on doc comments in the future.
Finally, the three tests I added should I think ideally not filter results by `CompletionKind::Keyword`, but if I want to get unfiltered results, I need access to a non-public function [get_all_completion_items](https://github.com/rust-analyzer/rust-analyzer/blob/9a4d02faf9c47f401b8756c3f7fcab2198f5f9cd/crates/ra_ide/src/completion/test_utils.rs#L32-L39) which I don't know if I should make public just for this.
5161: SSR: Add initial support for placeholder constraints r=matklad a=davidlattimore
5184: Always install required nightly extension if current one is not nightly r=matklad a=Veetaha
This is weird, but having switched back to stable by uninstalling the extension appears that vscode doesn't destroy the `PersistentState` and thus changing to `nightly` channel doesn't work because the last check for nightly extension was less than 1 hour ago. The simple solution is to skip this check if we know that the current extension version is not nightly.
5185: Force showing extension activation error pop-up notification r=matklad a=Veetaha
Fixesrust-lang/rust-analyzer#5091
5186: fix: correct pd/ppd/tfn/tmod completion doc r=matklad a=fannheyward
https://github.com/rust-analyzer/rust-analyzer/blob/a33eefa3b26000b3018e6bb873f18dbe15ab4ab7/crates/ra_ide/src/completion/complete_snippet.rs#L23-L24
Co-authored-by: BGluth <gluthb@gmail.com>
Co-authored-by: David Lattimore <dml@google.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
Co-authored-by: Heyward Fann <fannheyward@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@sanxiyn@pcwalton@bors