From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Randy Taylor Newsgroups: gmane.emacs.bugs Subject: bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties Date: Fri, 10 Feb 2023 03:44:07 +0000 Message-ID: References: <6209c097-0369-828a-7513-d8afb73fd7f0@secure.kjonigsen.net> <3e40d23f-1629-c5b7-1f17-d769790d6494@yandex.ru> <56a0b3d9-4a8f-0f81-83cb-6b78271dd782@yandex.ru> <3dc0ab0a-b0b1-91b8-f393-8db3899cf956@yandex.ru> <05ee38a5-f783-5b2c-add6-ee2ea27ba297@yandex.ru> <8a58c831-d8e6-c5b8-67b0-c606b2b3f189@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_9gSvzoBMAR8bS5sa66p175XXPJYQClXYDcGqNI2zC8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5999"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= , 61302@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 10 04:45:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pQKLi-0001LG-Ea for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Feb 2023 04:45:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQKLR-0004I0-KH; Thu, 09 Feb 2023 22:45:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQKLP-0004Hl-Hi for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 22:45:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pQKLO-00032X-Vd for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 22:45:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pQKLO-0001lr-A1 for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 22:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Randy Taylor Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Feb 2023 03:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61302 X-GNU-PR-Package: emacs Original-Received: via spool by 61302-submit@debbugs.gnu.org id=B61302.16760006736759 (code B ref 61302); Fri, 10 Feb 2023 03:45:02 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 10 Feb 2023 03:44:33 +0000 Original-Received: from localhost ([127.0.0.1]:34037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQKKu-0001kx-V1 for submit@debbugs.gnu.org; Thu, 09 Feb 2023 22:44:33 -0500 Original-Received: from mail-4323.proton.ch ([185.70.43.23]:55925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQKKr-0001kg-LC for 61302@debbugs.gnu.org; Thu, 09 Feb 2023 22:44:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1676000663; x=1676259863; bh=Wh7h+gKnCuT2py0D9B8krdVmcNjWaAWlnbCdxnz/8c4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=eGkdltrKIEfpu6FXHSG9UiCplEd8rdkLnMrK0+X7TyVjZrXtmHXRI73tLJGRHfG8/ 02XTO2jaKxEUYaf1dFP6uOezz0AC1R5kK6hBw4c/pUGy+EFH1rVRfus5b3eA0kT5MG Mr2pPnkq8/5+gJjcnUViEG7wBZb7TUAvqmUSRrbsIhdb7clzAIPjhUrVEFXKyPYaFq SGERZWt96XkKv9jdItwu/gl3frL4aq3doB3IAZ/3KnKQyQ+6hw4FRa78Xirx7rHGl4 PFaE/pqVU6JkDCJ0iT7i82zQuITlcnAol/MwR6K8ATL7GCEF7tnXaRiWqCvoLYiPT9 /7a6uLbFIzuDQ== In-Reply-To: <8a58c831-d8e6-c5b8-67b0-c606b2b3f189@yandex.ru> Feedback-ID: 44397038:user:proton X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:255268 Archived-At: This is a multi-part message in MIME format. --b1_9gSvzoBMAR8bS5sa66p175XXPJYQClXYDcGqNI2zC8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thursday, February 9th, 2023 at 16:19, Dmitry Gutov w= rote: >On 09/02/2023 05:38, Randy Taylor wrote: > >>> What if it looked like this: >>> >>> let date =3D DateTime::::from_utc(date, chrono::utc); >>> >>> If we decide purely based on capitalization, then I guess the rule >>> should be present in both lists (with capitalized? regexp in one, and >>> !capitalized? regexp in another), and a few more rules should be >>> duplicated as well. >> >> In both cases, utc is still a type even if it's not capitalized. >> My patch addresses this. > >So the end of a scoping chain must also be either a type or a method >call? We might be able to use that, somehow. I believe so (with the exception of use declarations as you note). Not familiar enough with Rust to say for sure :). > >Though the 'use' declarations might be exceptions, e.g. > > use crate::foo::baz::foobaz;crate > >or > > use std::{fmt, fs, usize}; > >(fmt and fs are modules, not types). > >>> This becomes a little more painful semantically, given that the first >>> 'utc' in the example above is parsed into a (type_identifier) node, not >>> just (identifier). >>> >>>>> On a distantly related note, we have terms like 'usize' which is >>>>> normally a type (and highlighted as such), but can also feature in >>>>> expressions like >>>>> >>>>> let row =3D usize::from_str_radix(row, 10).map_err(|_| error())?; >>>>> >>>>> where it is now highlighted with font-lock-constant-face. Should we t= ry >>>>> to do anything about that? If there is a limited number of built-in >>>>> types in that situation (e.g. all of them primitives), we could handl= e >>>>> that with a regexp. >>>> >>>> Right. I think it makes sense to handle the primitives with a regex. >>>> I'm not sure if there's anything else beyond those. >>>> There's a list of them here: https://doc.rust-lang.org/reference/types= .html >>>> I think it would only apply to the numerical and textual types. >>> >>> So 'usize' in the above is definitely a "type", not a "module"? >> >> I think so. You can see on usize's documentation page (https://doc.rust-= lang.org/std/primitive.usize.html) >> that it provides that function, amongst many others. > >I was thinking that it might also be referring to (apparently >deprecated) https://doc.rust-lang.org/std/usize/index.html. That module only provides the constants listed on that page. The usize type itself provides a bunch of constants and functions (same for= the rest of the primitives). I'm curious how other editors/IDEs highlight this stuff, but I don't have a= ny on hand ATM. > >Sorry, I'm not really familiar with Rust. E.g. in Ruby every class can >also serve as a "module" in the scoping sense. As a result we highlight >both classes and modules with font-lock-type-face. This could also be an >option here, if everything else fails. > >But we could also highlight based on a "role" (constant if it's used as >a scope, and type if it's used as a type). > >Although one could say that 'Path' in > > Some(Path::new("./foo")) > >is being used as a type as well, and 'Some' too. So it might not be the >best fit. > >Speaking of 'usize' again, what if some lib or the app defines an >'usize' module for its custom functions acting on it? E.g. >'my::app::usize'. A simple regexp matcher will probably highlight it as >a type as well. I don't think we should worry about those cases IMO. > >>>>> Or vice versa, in >>>>> >>>>> use std::{fmt, fs, usize}; >>>>> >>>>> should 'fmt', 'fs' and 'usize' be highlighted with >>>>> font-lock-constant-face rather than font-lock-type-face? >>>> >>>> They should indeed be highlighted with font-lock-constant-face because= they are modules. >>>> We assume the types will be capitalized since that's all we can really= do (and it's the convention anyway). >>> >>> If they're modules here, I suppose they should be highlighted the same = in >>> >>> let row =3D usize::from_str_radix(...) >>> >>> as well. The bright side is that will make a more complex regexp >>> (enumerating the lowercase named types) unnecessary. >> >> Yes, except for the primitives. >> >> I have attached a patch which I think addresses most of the concerns (al= though I've been at it for a few hours and my brain is mush now). >> >> The patch does the following: >> - Separates import-related stuff and module use by leveraging the use_de= claration query (simplifying things greatly IMO). >> - Highlights primitive types used in scoped_identifiers. >> - Properly highlights types belonging to a module no matter how deep it = is (or your money back guaranteed!). >> - Maybe some other stuff I forgot. I'm too tried now :). > >Thank you, I can sympathize -- this stuff gets complicated. > >Some problems from my testing: > >1. If I keep treesit-font-lock-level at its default value (3), some >stuff gets misfontified: Sorry, I have only been testing with level 4. This is also why I want type and module combined into one so we don't have = to deal with this headache. > > use std::collections::hash_map::{self, HashMap}; > >'hash_map' is highlighted as a type. 'HashMap' is not highlighted at all. > > use std::{fmt, fs, usize}; > >Only 'use' is highlighted here. This is because of how things are broken out into the module feature. That some highlighting for those occurs is by overlap of queries in the typ= e feature. Which again is why I think module should be part of type. > > test::test1(); > >'test1' is highlighted as a type (we discussed this problem with >highlighting types by default -- it becomes necessary to filter out >function calls, either with more complex queries, or with custom >highlighter functions). Right, I added a query to filter that out now. > >2. If I switch to treesit-font-lock-level 4: > > let boxed_i32 =3D Box::new(5_i32); > >'Box' is highlighted with font-lock-constant-face. I think it's a type, >though. Oops, I accidentally removed the rule for that. Added it back. > >Also here's a pre-existing problem mentioned above: > > use std::{fmt, fs, usize}; > >'fmt' and 'fs' are not types. But they are highlighted with >font-lock-type-face. This is really weird, I can reproduce it with emacs -Q but not with my norm= al config... Also with emacs -Q this: let date =3D DateTime::::from_utc(date, chrono::co= ol::this::Utc); highlights incorrectly, where "there" is font-lock-variable-name-face. But = with my normal config everything is fine. I'll look into it tomorrow. Not really sure what in my config could cause t= his... > >> A few questions: >> - Should module be moved to level 3 to be with type? >> - Do we still want the module feature, or should this stuff be put into = type? > >I suppose we should iron some kinds out first to get a better understandin= g. Attached a new patch hopefully addressing most of the problems you ran into= (minus the level 3 use declaration highlights). Especially after the problems you ran into at level 3, I strongly think the= module queries should get thrown into type (and they make sense there anyw= ay IMO). Then all those issues go away. --b1_9gSvzoBMAR8bS5sa66p175XXPJYQClXYDcGqNI2zC8 Content-Type: text/x-patch; name=0001-Fix-rust-ts-mode-type-and-module-highlighting.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=0001-Fix-rust-ts-mode-type-and-module-highlighting.patch RnJvbSAyY2I5YjU0Y2NhOTRjOGFlYjIwMTg3OGYyZTEzZDJlODRiZjcwZmNmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSYW5keSBUYXlsb3IgPGRldkByanQuZGV2PgpEYXRlOiBXZWQs IDggRmViIDIwMjMgMjE6NDM6MDQgLTA1MDAKU3ViamVjdDogW1BBVENIXSBGaXggcnVzdC10cy1t b2RlIHR5cGUgYW5kIG1vZHVsZSBoaWdobGlnaHRpbmcKCiogbGlzcC9wcm9nbW9kZXMvcnVzdC10 cy1tb2RlLmVsIChydXN0LXRzLW1vZGUtLWZvbnQtbG9jay1zZXR0aW5ncyk6CkFkZCBuZXcgJ21v ZHVsZScgZmVhdHVyZSBhbmQgc2ltcGxpZnkgJ3R5cGUnIGZlYXR1cmUuCihydXN0LXRzLW1vZGUp OiBBZGQgJ21vZHVsZScgZmVhdHVyZS4KLS0tCiBsaXNwL3Byb2dtb2Rlcy9ydXN0LXRzLW1vZGUu ZWwgfCA2NCArKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tCiAxIGZpbGUgY2hhbmdl ZCwgNTIgaW5zZXJ0aW9ucygrKSwgMTIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9w cm9nbW9kZXMvcnVzdC10cy1tb2RlLmVsIGIvbGlzcC9wcm9nbW9kZXMvcnVzdC10cy1tb2RlLmVs CmluZGV4IDVjNzFhOGFkNDYxLi45YjUxNDMyY2NiMyAxMDA2NDQKLS0tIGEvbGlzcC9wcm9nbW9k ZXMvcnVzdC10cy1tb2RlLmVsCisrKyBiL2xpc3AvcHJvZ21vZGVzL3J1c3QtdHMtbW9kZS5lbApA QCAtMjA0LDYgKzIwNCw0MSBAQCBydXN0LXRzLW1vZGUtLWZvbnQtbG9jay1zZXR0aW5ncwogICAg ICAgKHJhd19zdHJpbmdfbGl0ZXJhbCkKICAgICAgIChzdHJpbmdfbGl0ZXJhbCldIEBmb250LWxv Y2stc3RyaW5nLWZhY2UpCiAKKyAgIDpsYW5ndWFnZSAncnVzdAorICAgOmZlYXR1cmUgJ21vZHVs ZQorICAgYCgoc2NvcGVkX2lkZW50aWZpZXIgcGF0aDogKGNyYXRlKQorICAgICAgICAgICAgICAg ICAgICAgICAgbmFtZTogKGlkZW50aWZpZXIpIEBmb250LWxvY2stY29uc3RhbnQtZmFjZSkKKwor ICAgICAoc2NvcGVkX3VzZV9saXN0IHBhdGg6IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLWNvbnN0 YW50LWZhY2UpCisgICAgIChzY29wZWRfdXNlX2xpc3QgcGF0aDogKHNjb3BlZF9pZGVudGlmaWVy CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5hbWU6IChpZGVudGlmaWVyKSBAZm9udC1s b2NrLWNvbnN0YW50LWZhY2UpKQorCisgICAgICgodXNlX2RlY2xhcmF0aW9uCisgICAgICAgYXJn dW1lbnQ6IChzY29wZWRfaWRlbnRpZmllcgorICAgICAgICAgICAgICAgICAgcGF0aDogKF8pIEBm b250LWxvY2stY29uc3RhbnQtZmFjZQorICAgICAgICAgICAgICAgICAgbmFtZTogKGlkZW50aWZp ZXIpIEBmb250LWxvY2stdHlwZS1mYWNlKSkKKyAgICAgICg6bWF0Y2ggIl5bQS1aXSIgQGZvbnQt bG9jay10eXBlLWZhY2UpKQorICAgICAodXNlX2RlY2xhcmF0aW9uCisgICAgICBhcmd1bWVudDog KHNjb3BlZF9pZGVudGlmaWVyCisgICAgICAgICAgICAgICAgIG5hbWU6IChpZGVudGlmaWVyKSBA Zm9udC1sb2NrLWNvbnN0YW50LWZhY2UpKQorCisgICAgICh1c2VfZGVjbGFyYXRpb24KKyAgICAg IGFyZ3VtZW50OiAoc2NvcGVkX2lkZW50aWZpZXIKKyAgICAgICAgICAgICAgICAgcGF0aDogKHNj b3BlZF9pZGVudGlmaWVyCisgICAgICAgICAgICAgICAgICAgICAgICBwYXRoOiAoXykgQGZvbnQt bG9jay1jb25zdGFudC1mYWNlCisgICAgICAgICAgICAgICAgICAgICAgICBuYW1lOiAoaWRlbnRp ZmllcikgQGZvbnQtbG9jay1jb25zdGFudC1mYWNlKQorICAgICAgICAgICAgICAgICBuYW1lOiAo aWRlbnRpZmllcikgQGZvbnQtbG9jay1jb25zdGFudC1mYWNlKSkKKworICAgICAodXNlX2RlY2xh cmF0aW9uCisgICAgICBhcmd1bWVudDogKHNjb3BlZF91c2VfbGlzdAorICAgICAgICAgICAgICAg ICBwYXRoOiAoc2NvcGVkX2lkZW50aWZpZXIKKyAgICAgICAgICAgICAgICAgICAgICAgIHBhdGg6 IChfKSBAZm9udC1sb2NrLWNvbnN0YW50LWZhY2UKKyAgICAgICAgICAgICAgICAgICAgICAgIG5h bWU6IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLWNvbnN0YW50LWZhY2UpKSkKKworICAgICAoKHVz ZV9saXN0IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLXR5cGUtZmFjZSkKKyAgICAgICg6bWF0Y2gg Il5bQS1aXSIgQGZvbnQtbG9jay10eXBlLWZhY2UpKQorICAgICAodXNlX2xpc3QgKGlkZW50aWZp ZXIpIEBmb250LWxvY2stY29uc3RhbnQtZmFjZSkpCisKICAgIDpsYW5ndWFnZSAncnVzdAogICAg OmZlYXR1cmUgJ3R5cGUKICAgIGAoKGVudW1fdmFyaWFudCBuYW1lOiAoaWRlbnRpZmllcikgQGZv bnQtbG9jay10eXBlLWZhY2UpCkBAIC0yMjAsMTkgKzI1NSwyMyBAQCBydXN0LXRzLW1vZGUtLWZv bnQtbG9jay1zZXR0aW5ncwogICAgICAgKDptYXRjaCAiXltBLVpdIiBAZm9udC1sb2NrLXR5cGUt ZmFjZSkpCiAgICAgICgoc2NvcGVkX2lkZW50aWZpZXIgcGF0aDogKGlkZW50aWZpZXIpIEBmb250 LWxvY2stdHlwZS1mYWNlKQogICAgICAgKDptYXRjaCAiXltBLVpdIiBAZm9udC1sb2NrLXR5cGUt ZmFjZSkpCi0gICAgICgoc2NvcGVkX2lkZW50aWZpZXIKLSAgICAgICAgKHNjb3BlZF9pZGVudGlm aWVyCi0gICAgICAgICBwYXRoOiAoaWRlbnRpZmllcikgQGZvbnQtbG9jay10eXBlLWZhY2UpKQot ICAgICAgKDptYXRjaCAiXltBLVpdIiBAZm9udC1sb2NrLXR5cGUtZmFjZSkpCi0gICAgICgoc2Nv cGVkX2lkZW50aWZpZXIKLSAgICAgICBwYXRoOiBbKGlkZW50aWZpZXIpIEBmb250LWxvY2stdHlw ZS1mYWNlCi0gICAgICAgICAgICAgIChzY29wZWRfaWRlbnRpZmllcgotICAgICAgICAgICAgICAg bmFtZTogKGlkZW50aWZpZXIpIEBmb250LWxvY2stdHlwZS1mYWNlKV0pCi0gICAgICAoOm1hdGNo ICJeW0EtWl0iIEBmb250LWxvY2stdHlwZS1mYWNlKSkKLSAgICAgKHNjb3BlZF90eXBlX2lkZW50 aWZpZXIgcGF0aDogKGlkZW50aWZpZXIpIEBmb250LWxvY2stdHlwZS1mYWNlKQorICAgICAoKHNj b3BlZF9pZGVudGlmaWVyIHBhdGg6IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLXR5cGUtZmFjZSkK KyAgICAgICg6bWF0Y2gKKyAgICAgICAiXlxcKHU4XFx8dTE2XFx8dTMyXFx8dTY0XFx8dTEyOFxc fHVzaXplXFx8aThcXHxpMTZcXHxpMzJcXHxpNjRcXHxpMTI4XFx8aXNpemVcXHxjaGFyXFx8c3Ry XFwpJCIKKyAgICAgICBAZm9udC1sb2NrLXR5cGUtZmFjZSkpCisgICAgIChzY29wZWRfaWRlbnRp ZmllciBwYXRoOiAoXykgQGZvbnQtbG9jay1jb25zdGFudC1mYWNlCisgICAgICAgICAgICAgICAg ICAgICAgICBuYW1lOiAoaWRlbnRpZmllcikgQGZvbnQtbG9jay10eXBlLWZhY2UpCisgICAgIChz Y29wZWRfaWRlbnRpZmllciBwYXRoOiAoc2NvcGVkX2lkZW50aWZpZXIKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBuYW1lOiAoaWRlbnRpZmllcikgQGZvbnQtbG9jay1jb25zdGFudC1m YWNlKSkKKyAgICAgKHNjb3BlZF90eXBlX2lkZW50aWZpZXIgcGF0aDogKF8pIEBmb250LWxvY2st Y29uc3RhbnQtZmFjZSkKKyAgICAgKHNjb3BlZF90eXBlX2lkZW50aWZpZXIKKyAgICAgIHBhdGg6 IChzY29wZWRfaWRlbnRpZmllcgorICAgICAgICAgICAgIHBhdGg6IChfKSBAZm9udC1sb2NrLWNv bnN0YW50LWZhY2UKKyAgICAgICAgICAgICBuYW1lOiAoaWRlbnRpZmllcikgQGZvbnQtbG9jay1j b25zdGFudC1mYWNlKSkKICAgICAgKHR5cGVfaWRlbnRpZmllcikgQGZvbnQtbG9jay10eXBlLWZh Y2UKICAgICAgKHVzZV9hc19jbGF1c2UgYWxpYXM6IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLXR5 cGUtZmFjZSkKLSAgICAgKHVzZV9saXN0IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLXR5cGUtZmFj ZSkpCisgICAgIDs7IEVuc3VyZSBmdW5jdGlvbiBjYWxscyBhcmVuJ3QgaGlnaGxpZ2h0ZWQgYXMg dHlwZXMuCisgICAgIChjYWxsX2V4cHJlc3Npb24gZnVuY3Rpb246IChzY29wZWRfaWRlbnRpZmll ciBuYW1lOiAoaWRlbnRpZmllcikgQGRlZmF1bHQpKSkKIAogICAgOmxhbmd1YWdlICdydXN0CiAg ICA6ZmVhdHVyZSAncHJvcGVydHkKQEAgLTM0NCw3ICszODMsOCBAQCBydXN0LXRzLW1vZGUKICAg ICAgICAgICAgICAgICAgICgga2V5d29yZCBzdHJpbmcpCiAgICAgICAgICAgICAgICAgICAoIGF0 dHJpYnV0ZSBidWlsdGluIGNvbnN0YW50IGVzY2FwZS1zZXF1ZW5jZQogICAgICAgICAgICAgICAg ICAgICBudW1iZXIgdHlwZSkKLSAgICAgICAgICAgICAgICAgICggYnJhY2tldCBkZWxpbWl0ZXIg ZXJyb3IgZnVuY3Rpb24gb3BlcmF0b3IgcHJvcGVydHkgdmFyaWFibGUpKSkKKyAgICAgICAgICAg ICAgICAgICggYnJhY2tldCBkZWxpbWl0ZXIgZXJyb3IgZnVuY3Rpb24gbW9kdWxlCisgICAgICAg ICAgICAgICAgICAgIG9wZXJhdG9yIHByb3BlcnR5IHZhcmlhYmxlKSkpCiAKICAgICA7OyBJbWVu dS4KICAgICAoc2V0cS1sb2NhbCB0cmVlc2l0LXNpbXBsZS1pbWVudS1zZXR0aW5ncwotLSAKMi4z OS4xCgo= --b1_9gSvzoBMAR8bS5sa66p175XXPJYQClXYDcGqNI2zC8--