WIP: Add semantic hightlighting to assembly inside asm! and global_asm!
#8738
Conversation
|
You could limit comment highlighting to |
|
oh interesting! I wasn't aware of that, thanks :) |
| } | ||
| } | ||
|
|
||
| fn lex_asm_string<F>(string: &ast::String, mut callback: F) |
There was a problem hiding this comment.
Would you like to publish & maintain a crate for syntax analysis of rust-flavored asm? ^^ It seems like this is a generally re-usable bit of functionality.
There was a problem hiding this comment.
Oh wait, right, the syntax is arch-specific... Hm, I guess, you know more about this than I do, but do consider if we could salvage some re-usability here?
There was a problem hiding this comment.
I wouldn't be opposed to extracting it out into its own crate(s) :) I think it could probably be a single crate since the formats aren't usually particularly complicated so each arch would probably just be a module.
There was a problem hiding this comment.
oh, I meant to ask: what did you have in mind with "syntax analysis of rust-flavored asm"? I'm assuming that includes tracking labels and such between different asm! blocks to try and give more complete information to the user? is there anything else? I suppose it may also be possible to give some information about the "type" of labels and such as well 🤔
There was a problem hiding this comment.
I don’t know what is this exactly, but I imagine you need to pars asm to do things like:
- completion of instructions
- instruction explanations in hover
- Highlighting targets of jumps
- Highlighting syntax errors in asm blocks
There was a problem hiding this comment.
ooohhh, that wasn't something I was thinking of, but that sounds awesome :o the "instruction explanations in hover" is something I actually really like about Godbolt's asm explorer and that'd be fantastic to have inline here! in this case, is this something that would be fairly coupled with r-a's crate ecosystem?
it actually is fairly easy, you can get diff --git a/crates/ide/src/syntax_highlighting.rs b/crates/ide/src/syntax_highlighting.rs
index 9df8d21af..519ad6219 100644
--- a/crates/ide/src/syntax_highlighting.rs
+++ b/crates/ide/src/syntax_highlighting.rs
@@ -59,6 +59,10 @@ pub(crate) fn highlight(
) -> Vec<HlRange> {
let _p = profile::span("highlight");
let sema = Semantics::new(db);
+ if let Some(m) = sema.to_module_def(file_id) {
+ let cfg = m.krate().cfg(db);
+ eprintln!("cfg = {:?}", cfg);
+ }
// Determine the root based on the given range.
let (root, range_to_highlight) = { |
|
@repnop any updates here? :) |
|
oh, somehow I missed that you posted something! I need to get better about checking my notifications 😅 I can take a look at those soon and reply :) |
oh, that's quite convenient! does this include being able to check |
|
I don't think it needs to be -- what I imagine is some crate for parsing
and otherwise "understanding" assembly syntax, which takes a `&str` as an
input and produces some form of an AST. As it should work on one snippet at
a time, it doesn't have to have tight integrations with salsa and the rest
of the jungle
…On Tue, 25 May 2021 at 18:14, Wesley Norris ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In crates/ide/src/syntax_highlighting/asm.rs
<#8738 (comment)>
:
> +}
+
+fn highlight_asm_part(kind: AsmPart) -> HlTag {
+ match kind {
+ AsmPart::Comment => HlTag::Comment,
+ AsmPart::Directive => HlTag::Attribute,
+ AsmPart::FormatIdentifier => HlTag::Symbol(SymbolKind::Local),
+ AsmPart::FormatOpen | AsmPart::FormatClose => HlTag::FormatSpecifier,
+ AsmPart::Instruction => HlTag::Symbol(SymbolKind::Function),
+ AsmPart::Label => HlTag::Symbol(SymbolKind::LifetimeParam),
+ AsmPart::NumericLiteral => HlTag::NumericLiteral,
+ AsmPart::Register => HlTag::Symbol(SymbolKind::Static),
+ }
+}
+
+fn lex_asm_string<F>(string: &ast::String, mut callback: F)
ooohhh, that wasn't something I was thinking of, but that sounds awesome
:o the "instruction explanations in hover" is something I actually really
like about Godbolt's asm explorer and that'd be fantastic to have inline
here! in this case, is this something that would be fairly coupled with
r-a's crate ecosystem?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8738 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANB3M6EAX2NDWQB3KI3G63TPO5G7ANCNFSM44GAMEHQ>
.
|
|
gotcha! I'll find some time soon to start sketching out a crate for this and post some updates here after that :) |
|
Let's close this to keep the queue manageble, feel free to re-open when there are updates! |
Attempt at #6031, very early WIP proof of concept PR. (see #6031 (comment) for an example screenshot)
It currently relies on some common conventions between assembly dialects, however this is definitely not ideal as, for instance,
#indicates a comment in RISC-V assembly, but an integer literal in ARM assembly. If theasm!macro ends up namespaced into the specificcore::arch::<name>modules, this should be more straightforward to figure out which architecture the assembly is for. The alternatives are:1a. I assume this could be extremely awkward considering that the highlighting is done fairly high up in the stack, from my understanding.
2a. This has the downside of needing a lot more information about the instructions available to each architecture, and can easily be inaccurate for small, single-to-few line
asm!snippets.Assuming we can do either reliably, per-architecture highlighters are the way forward here I believe. It will likely still not be perfect as we'll only have the textual knowledge of the syntax and miss some details, e.g. a symbol defined somewhere else, but I believe even somewhat incomplete/inaccurate highlighting would be a massive improvement for working on low-level code that needs to make liberal use of
asm!/global_asm!.Additional discussion on deciding which semantic tokens types should map to assembly constructs is also a pretty complex problem to solve, I think. Likely will be a decent bit of bikeshedding, but I think I came to a somewhat sensible default for the initial proof of concept.
Feedback and suggestions welcomed :)