text:
bank tags

can right click a bank item and save as a certain tag so when you search "bard" can get all his items

Currently, I believe the big issue with implementing bank tags is that we don't have a good way to store lists or maps, since the ConfigManager is backed by a .properties file, which doesn't appear to store any type information

Decompiled CS2 and found these scripts.
Script 509
[proc,script509](int $int0, int $int1, int $int2, int $int3, int $int4, int $int5, int $int6, int $int7, int $int8, int $int9, int $int10, int $int11)(int)
$int12 = 0;
if($int11 == 0 && $int2 > 0 && ~script514 == 1) {
    $int12 = add($int8, 15);
} else {
    $int12 = $int8;
}
$int13 = -1;
$int14 = 0;
$int15 = 0;
$int16 = 0;
while($int0 < $int1) {
    if(cc_find($int3, $int0) == 1) {
        $int13 = inv_getobj(95, $int0);
        if(~script279($int13) == 1) {
            cc_sethide(0);
            ~script278($int13, inv_getnum(95, $int0), $int3, $int4, $int5, $int6, $int7);
            $int14 = add($int12, multiply($int16, 36));
            cc_setposition(multiply($int15, add(36, $int9)), $int14, 0, 0);
            $int14 = add($int14, 32);
            if($int15 < $int10) {
                $int15 = add($int15, 1);
            } else {
                $int16 = add($int16, 1);
                $int15 = 0;
            }
        }
    }
    $int0 = add($int0, 1);
}
if($int14 <= 0) {
    return($int8);
}
if($int11 == 0) {
    if($int15 > 0) {
        if(cc_find($int3, add(add(816, multiply(9, 2)), $int2)) == 1) {
            cc_sethide(0);
            cc_setposition(multiply($int15, add(36, $int9)), sub($int14, 32), 0, 0);
            $int15 = sub(8, $int15);
            cc_setsize(add(multiply($int15, 36), multiply(sub($int15, 1), $int9)), 32, 0, 0);
        }
    }
    if($int12 > $int8) {
        if(cc_find($int3, sub(add(add(816, 9), $int2), 1)) == 1) {
            cc_setposition(0, $int8, 0, 0);
            cc_sethide(0);
        }
    }
}
return($int14);

Script 514
[proc,script514](int)
if(%varc5 == 11 || string_length(%varcstr22) > 0) {
    if(%varc5 <= 0) {
        return(1);
    }
}
return(0);

Script 279
[proc,script279](int $int0)(int)
$string0 = "";
$string1 = "";
if(~script514 == 1) {
    $string1 = ~script280;
    if(string_length($string1) > 0) {
        if($int0 != -1) {
            $string0 = lowercase(oc_name($int0));
        }
        if(string_indexof_string($string0, $string1, 0) != -1) {
            return(1);
        }
        return(0);
    }
}
return(1);

Script 280
[proc,script280](string)
$string0 = lowercase(%varcstr22);
if(string_length($string0) <= 16) {
    return($string0);
}
return(substring($string0, 0, 15));

Proof of concept: https://github.com/Adam-/runelite/commit/c126e5e70130455e0ad9316c8c739f3c7e4e3a26

authors: Adam- Joshua-F SomeoneWithAnInternetConnection Urbannights


text:
NPC Highlight Plugin

This plugin allows users to highlight NPCs.
You can specify a list of NPC names which will then highlight all NPCs that match that name.
An optional 'Tag' option can be added to NPCs which will allow users to highlight an individual NPC.
relevant issue

Does anyone know how Konduit draws their npc tags? I think they get the renderer to outline it instead of doing an overlay, since it seems to respect draw order etc.

source: gharchive/pull-request

authors: Adam- McSwindler

repo: runelite/runelite

license_type: permissive

license_source: github-api


text:
Improvements to map unification

This fixes #319 and hopefully also #298 by newly allowing unification of:

Two maps with multiple fully concrete keys and no "rest" map variable (previously we could only match multiple keys if there was also a "rest of the map" variable)
Map with only concrete keys + "rest" variable with a map of mixed koncerte/symbolic keys without a "rest" variable

Kontrol performance:
 Test                                                                                | sam-map-unification-improvements time | master time | (sam-map-unification-improvements/master) time
---------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-------------+------------------------------------------------
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[AddrTest.test_notBuiltinAddress_concrete()]               | 55.89                                 | 53.95       | 1.0359592215013902
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[PlainPrankTest.test_startPrankWithOrigin_true()]          | 211.98                                | 204.39      | 1.0371348891824455
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[ExpectRevertTest.testFail_expectRevert_empty()]           | 76.69                                 | 73.88       | 1.0380346507850569
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[ExpectRevertTest.test_expectRevert_message()]             | 151.49                                | 145.89      | 1.0383850846528209
 src/tests/integration/test_foundry_prove.py::test_foundry_fail[AssertTest.test_revert_branch(uint256,uint256)]            | 114.17                                | 109.12      | 1.0462793255131964
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[ArithmeticTest.test_max1(uint256,uint256)]                | 123.0                                 | 117.47      | 1.0470758491529752
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[LoopsTest.test_sum_10()]                                  | 96.54                                 | 91.73       | 1.052436498419274
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[EmitContractTest.testExpectEmitCheckEmitter()]            | 143.76                                | 135.58      | 1.060333382504794
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[AddrTest.test_addr_true()]                                | 66.52                                 | 62.15       | 1.0703137570394208
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[ExpectRevertTest.testFail_ExpectRevert_failAndSuccess()]  | 163.32                                | 151.16      | 1.0804445620534533
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[ExpectRevertTest.testFail_expectRevert_multipleReverts()] | 179.1                                 | 164.95      | 1.085783570779024
 src/tests/integration/test_foundry_prove.py::test_foundry_prove[BMCLoopsTest.test_countdown_concrete()]                   | 62.16                                 | 56.58       | 1.0986214209968186
 src/tests/integration/test_solc_to_k.py::test_solc_to_k[Empty.sol]                                                        | 55.9                                  | 50.21       | 1.1133240390360486
 src/tests/integration/test_solc_to_k.py::test_solc_to_k[ERC721.sol]                                                       | 56.53                                 | 48.85       | 1.1572159672466735
 TOTAL                                                                                | 1557.05                               | 1465.91     | 1.062172984698924

Kevm performance:
 Test                                                                                | sam-map-unification-improvements time | master time        | (sam-map-unification-improvements/master) time
-------------------------------------------------------------------------------------------+---------------------------------------+--------------------+------------------------------------------------
 src/tests/integration/test_prove.py::test_pyk_prove[erc20/hkg/approve-spec.k]             | 70.66                                 | 76.6               | 0.9224543080939948
 src/tests/integration/test_prove.py::test_pyk_prove[erc20/ds/transfer-failure-1-b-spec.k] | 169.29                                | 160.45             | 1.055095045185416
 TOTAL                                                                                | 239.95                                | 237.04999999999998 | 1.0122337059692048

repo: runtimeverification/hs-backend-booster


text:
Allow non-admin users to generate API key to access their records

What happened?
Hi,
Is it possible/planned to allow individual users to generate API keys which allows them to access their records/data?
Thanks.
How to reproduce the bug
N/A
Package Version
00
PHP Version
00
Laravel Version
00
Which operating systems does with happen with?
No response
Notes
No response

ill be add it to our milestone

Yes, please do it. Becouse there is no role in users on some simple projects

Yes, please do it. Becouse there is no role in users on some simple projects

I think you have a different issue, in this issue is still using a role and permission. But the users can manage their own token.
But as you mentioned, u project didnt use role.
am i right @entrailz ?

did u mean, you need a public API or something else @Odilbukh ?

@rupadana Yes, I mean public API. There is no users' role in my system. But I need API. Your package is very usefull in this case. But Token resource show and can create new token only super_admin role.

@rupadana Yes, I mean public API. There is no users' role in my system. But I need API. Your package is very usefull in this case. But Token resource show and can create new token only super_admin role. Now I dont know how to fix it

Yesterday we release version 3.0.7 and u can read Readme

Thank you for your input. this feature is already now on version 3.0.9.

source: gharchive/issue

authors: Odilbukh entrailz rupadana

repo: rupadana/filament-api-service

license: MIT


text:
[Feature]

Description
I want to add figma design link for other devices.
Screenshots
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

@CBID2 please assign this to me.

@CBID2 please assign this to me.
Sure, could you please elaborate on the issue more?

I will add figma design prototype of existing one for other devices like tablet etc

Just a replica of it @rupali-codes

Just a replica of it @rupali-codes

Oh, great, thanks

need figma link access @CBID2 @rupali-codes

need figma link access @CBID2 @rupali-codes

We don't have an account with Figma @Abhinavcode13.

What to do now? @CBID2

#839 assign me this issue anyways

#839 assign me this issue anyways

You figured it out?

Me Idea was to create same replica figma frame for tablets , but I don't have any access to it.

Me Idea was to create same replica figma frame for tablets , but I don't have any access to it.

Ohh now I get. I think you'll have to wait for @rupali-codes because I don't have access to the link either

repo: rupali-codes/LinksHub


text:
Doc links not resolving

This must be a recent change because crate links like https://rusoto.org/rusoto/rusoto_core/index.html previously worked

Yup, my bad, when trying to remove the outdated and misleading copy of our gitbook, I managed to muck it up.
Working on fixing it!
In the meantime, the docs for published versions are available on docs.rs.

Should be all fixed up. I may have to do more tweaks to accomplish my goal of cleaning up our old gitbook, but I will hopefully not blow things up again.

Chrome's caching of redirects got me all messed up, but everything appears to work now.
Ticket causing the issues: https://github.com/rusoto/rusoto.github.io/issues/80 . Now done! 👍

Ah, one thing to note: with the CNAME messing I did with the https://github.com/rusoto/rusoto.github.io repo, the actual link is https://rusoto.github.io/rusoto/rusoto_core/index.html .
With the CNAME incorrectly in place it was redirecting to https://rusoto.org/rusoto/rusoto_core/index.html . Note the difference in domains. As far as I know, we haven't had our API docs available on rusoto.org, just rusoto.github.io . Tricky to follow and not the first time we've run into confusion. A recent clarification is here: https://github.com/rusoto/rusoto/issues/904#issuecomment-354936212 .

authors: matthewkmayer softprops

repo: rusoto/rusoto

license: mit

license_source: bigquery


text:
Fix Route 53 POST APIs

This should fix #765 .
The root cause is split into two parts;

In Route 53, no operation has "payload" parameter but some API actually
requires payload. In that case, the payload should include members whose
"location" parameter is missing.
XML element name of each list element was wrong

I confirmed that ChangeResourceRecordSets works in simple cases at least.

Thanks for the pull request.  This looks good at a quick skim.  I'm in between sessions at a conference right now, but I should be able to give this a serious review tonight or tomorrow.

I'm planning the next pull request to fix rest-xml APIs. I think it should use xml::EventWriter instead of format! and naive string concatenations.
https://github.com/eagletmt/rusoto/compare/fix-route53-post-api...eagletmt:xml-writer

Looks great, thanks!

authors: adimarco eagletmt matthewkmayer


text:
Add bindings for sqlite3_trace_v2 API

The trace feature flag currently enables the deprecated tracing functions. It should provide access to the new sqlite3_trace_v2 API as well.

https://github.com/rusqlite/rusqlite/blob/b41bd805710149ebfaed577dfedb464338e2ca97/src/trace.rs#L120
And the old functions seem not really deprecated at least on this page:
http://sqlite.org/c3ref/funclist.html

functions whose names are struck through are deprecated.

Interesting point, reported on the SQLite forum. Either way, I'd like access to the v2 API, since it structures the data in a way that's nicer for generating spans to integrate into my tracing system, which is what I want to do.
Should this issue be merged into #977, or kept separate?

You can keep it separate.

authors: WesleyAC gwenn

repo: rusqlite/rusqlite


text:
Fix "unused function" waring from rustc to only color the name of the function

Currently, unused functions are rendered as:

That is, rustc uses the span of the whole function for diagnostic. It instead should use only the name of the function.
Note that this is diagnostic which comes from rustc, so I think it should be fixed there (unless we are somehow using the wrong span here).
cc @estebank, is there some existing issue at rust-lang/rust for this?

I don't think there's a ticket for it, but it should be very easy to fix.

Yup, fixed, thanks! (missed the edit originally)

authors: estebank matklad

repo: rust-analyzer/rust-analyzer


text:
internal: Revert attributed items inlay hints

Reverts #10231 as the implementation there is actually wrong
bors r+

changelog skip

authors: Veykril lnicola


text:
"fill match arms" assist: Match on bind patterns

This prevents duplication of match arms where the pre-existing arm is a bind pattern.

bors r+


text:
Document "consuming" semantic tokens modifier

cc https://github.com/rust-analyzer/rust-analyzer/pull/5957/files

bors r+

authors: Veetaha jonas-schievink


text:
fix for #8664: Emit folding ranges for multi-line where clauses

#8664
I added a test that assert folding multi-line where clauses while leaving single lined one. Please, let me know if the code needs further improvements.

There is_multiline check being done above already. For not hiding the where
clause itself, yeah, I guess we need a special case, but it seems that the
special case is better fit for the common code-path, not for the
continious_range one.
On Tue, 27 Apr 2021 at 17:39, m5tfi @.***> wrote:

@.**** commented on this pull request.
In crates/ide/src/folding_ranges.rs
https://github.com/rust-analyzer/rust-analyzer/pull/8674#discussion_r621274839
:

           // Fold where clause

           if node.kind() == WHERE_CLAUSE && !visited_where_clauses.contains(&node) {

               if let Some(range) =

                   contiguous_range_for_where(&node, &mut visited_where_clauses)

               {

                   res.push(Fold { range, kind: FoldKind::WhereClause })

               }

           }

But when we fold the where clause as a whole, it hides the where keyword
fn foo()where
A: Foo,
B: Foo,
C: Foo,
D: Foo, {}
will be:
fn foo()/* */ {}
instead of
fn foo()where /* */ {}
and i won't be able to check if it's a multi-line where clause or not, am
I missing something ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-analyzer/rust-analyzer/pull/8674#discussion_r621274839,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANB3M3M4NCADY3QSOMS33DTK3EDTANCNFSM43T7UENQ
.

There is_multiline check being done above already

According to rustfmt (here). The indent_style of the where predicates defaults to "block". so, there will always be a newline \n.
fn foo()
where
    A: Foo,
{
}

Therefore, the is_multiline check above will always count where clauses as multi-line even if there was only one predicate.
So, I check if the first predicate matches the last one to make sure it's more than one, and start the fold at the end of the where keyword (second token) and end the fold at the end of the last comma (last token).
fn contiguous_range_for_where(
    node: &SyntaxNode,
    visited: &mut FxHashSet<SyntaxNode>,
) -> Option<TextRange> {
    let first_where_pred = node.first_child();
    let last_where_pred = node.last_child();

    if first_where_pred != last_where_pred {
        let mut it = node.descendants_with_tokens();
        if let (Some(_where_clause), Some(where_kw), Some(last_comma)) =
            (it.next(), it.next(), it.last())
        {
            let start = where_kw.text_range().end();
            let end = last_comma.text_range().end();

            visited.insert(node.clone());
            return Some(TextRange::new(start, end));
        }
    }
    None
}

I think my naming for the function might be misleading.

I am sorry, It's my third contribution ever on github and I made a couple of mistakes.
TLDR It is passing all the tests on my machine now.
I was working inside the ide crate and forgot to run tests for the whole project (outside the ide crate) before pushing. Then, I thought that I should merge with the recent commit in the original repo before trying to fix the failed test, but that failed another test (tidy::check_merge_commits) as I didn't know that I am not allowed to merge. So, I followed the stdout instructions, made a soft reset and fixed the issues.
Now, It's passing all of the tests on my machine. Can we try the github tests again please?

No worries about git! It took we a while to figure out a good workflow again. The tests are re-run automatically after every push.

I think my naming for the function might be misleading.

Yeah, seems like it! It looks like we handle  where clauses like a special case -- they are unlike items like mods that can be folded completely, and they are unlike items like uses or commets, which are folded if there's a consequiteve group of them.
So let's reflect this in code, and handle where clauses separaetly, without trying to mimic existing code.
In  particular, visited_where_clauses.contains(&node) seems to be just a remenant of consequitve logic and isn't needed for where clauses?

visited_where_clauses.contains(&node) seems to be just a remenant of consequitve logic and isn't needed for where clauses

That's true, sorry about that, i removed it now. I also renamed the function name to a better name (i think).

The tests are re-run automatically after every push.

It keeps giving me this message :

Shame on you for not trusting noobs (I am just kidding).

There's something I faced and couldn't solve. All the tests ran successfully locally on my Linux and on Github, but when I tried to run the tests locally on Windows10, It failed 2 tests:

tests::lexer_tests
tests::parser_tests

I checkout the oldest commit, before any of my changes, and these 2 tests still failed. Should I create an issue for it, or is it just something wrong with my development environment ?

failures:

---- tests::lexer_tests stdout ----

error: expect test failed
   --> D:\monkey\rust-analyzer\crates/syntax/test_data\lexer/ok\0006_chars.txt

You can update all `expect![[]]` tests by running:

    env UPDATE_EXPECT=1 cargo test

To update a single test, place the cursor on `expect` token and use `run` feature of rust-analyzer.

Expect:
----
CHAR 3 "\'x\'"
WHITESPACE 1 " "
CHAR 3 "\' \'"
WHITESPACE 1 " "
CHAR 3 "\'0\'"
WHITESPACE 1 " "
CHAR 7 "\'hello\'"
WHITESPACE 1 " "
CHAR 6 "\'\\x7f\'"
WHITESPACE 1 " "
CHAR 4 "\'\\n\'"
WHITESPACE 1 " "
CHAR 4 "\'\\\\\'"
WHITESPACE 1 " "
CHAR 4 "\'\\\'\'"
WHITESPACE 1 "\n"

----

Actual:
----
CHAR 3 "'x'"
WHITESPACE 1 " "
CHAR 3 "' '"
WHITESPACE 1 " "
CHAR 3 "'0'"
WHITESPACE 1 " "
CHAR 7 "'hello'"
WHITESPACE 1 " "
CHAR 6 "'\\x7f'"
WHITESPACE 1 " "
CHAR 4 "'\\n'"
WHITESPACE 1 " "
CHAR 4 "'\\\\'"
WHITESPACE 1 " "
CHAR 4 "'\\''"
WHITESPACE 1 "\n"

----

Diff:
----
CHAR 3 "\'x\'"
WHITESPACE 1 " "
CHAR 3 "\' \'"
WHITESPACE 1 " "
CHAR 3 "\'0\'"
WHITESPACE 1 " "
CHAR 7 "\'hello\'"
WHITESPACE 1 " "
CHAR 6 "\'\\x7f\'"
WHITESPACE 1 " "
CHAR 4 "\'\\n\'"
WHITESPACE 1 " "
CHAR 4 "\'\\\\\'"
WHITESPACE 1 " "
CHAR 4 "\'\\\'\''"
WHITESPACE 1 "\n"

----

---- tests::parser_tests stdout ----

error: expect test failed
   --> D:\monkey\rust-analyzer\crates/syntax/test_data\parser/inline/ok\0003_where_pred_for.rast

Expect:
----
SOURCE_FILE@0..54
  FN@0..53
    FN_KW@0..2 "fn"
    WHITESPACE@2..3 " "
    NAME@3..12
      IDENT@3..12 "for_trait"
    GENERIC_PARAM_LIST@12..15
      L_ANGLE@12..13 "<"
      TYPE_PARAM@13..14
        NAME@13..14
          IDENT@13..14 "F"
      R_ANGLE@14..15 ">"
    PARAM_LIST@15..17
      L_PAREN@15..16 "("
      R_PAREN@16..17 ")"
    WHITESPACE@17..18 "\n"
    WHERE_CLAUSE@18..49
      WHERE_KW@18..23 "where"
      WHITESPACE@23..27 "\n   "
      WHERE_PRED@27..49
        FOR_KW@27..30 "for"
        GENERIC_PARAM_LIST@30..34
          L_ANGLE@30..31 "<"
          LIFETIME_PARAM@31..33
            LIFETIME@31..33
              LIFETIME_IDENT@31..33 "\'a"
          R_ANGLE@33..34 ">"
        WHITESPACE@34..35 " "
        PATH_TYPE@35..36
          PATH@35..36
            PATH_SEGMENT@35..36
              NAME_REF@35..36
                IDENT@35..36 "F"
        COLON@36..37 ":"
        WHITESPACE@37..38 " "
        TYPE_BOUND_LIST@38..49
          TYPE_BOUND@38..49
            PATH_TYPE@38..49
              PATH@38..49
                PATH_SEGMENT@38..49
                  NAME_REF@38..40
                    IDENT@38..40 "Fn"
                  PARAM_LIST@40..49
                    L_PAREN@40..41 "("
                    PARAM@41..48
                      REF_TYPE@41..48
                        AMP@41..42 "&"
                        LIFETIME@42..44
                          LIFETIME_IDENT@42..44 "\'a"
                        WHITESPACE@44..45 " "
                        PATH_TYPE@45..48
                          PATH@45..48
                            PATH_SEGMENT@45..48
                              NAME_REF@45..48
                                IDENT@45..48 "str"
                    R_PAREN@48..49 ")"
    WHITESPACE@49..50 "\n"
    BLOCK_EXPR@50..53
      L_CURLY@50..51 "{"
      WHITESPACE@51..52 " "
      R_CURLY@52..53 "}"
  WHITESPACE@53..54 "\n"

----

Actual:
----
SOURCE_FILE@0..54
  FN@0..53
    FN_KW@0..2 "fn"
    WHITESPACE@2..3 " "
    NAME@3..12
      IDENT@3..12 "for_trait"
    GENERIC_PARAM_LIST@12..15
      L_ANGLE@12..13 "<"
      TYPE_PARAM@13..14
        NAME@13..14
          IDENT@13..14 "F"
      R_ANGLE@14..15 ">"
    PARAM_LIST@15..17
      L_PAREN@15..16 "("
      R_PAREN@16..17 ")"
    WHITESPACE@17..18 "\n"
    WHERE_CLAUSE@18..49
      WHERE_KW@18..23 "where"
      WHITESPACE@23..27 "\n   "
      WHERE_PRED@27..49
        FOR_KW@27..30 "for"
        GENERIC_PARAM_LIST@30..34
          L_ANGLE@30..31 "<"
          LIFETIME_PARAM@31..33
            LIFETIME@31..33
              LIFETIME_IDENT@31..33 "'a"
          R_ANGLE@33..34 ">"
        WHITESPACE@34..35 " "
        PATH_TYPE@35..36
          PATH@35..36
            PATH_SEGMENT@35..36
              NAME_REF@35..36
                IDENT@35..36 "F"
        COLON@36..37 ":"
        WHITESPACE@37..38 " "
        TYPE_BOUND_LIST@38..49
          TYPE_BOUND@38..49
            PATH_TYPE@38..49
              PATH@38..49
                PATH_SEGMENT@38..49
                  NAME_REF@38..40
                    IDENT@38..40 "Fn"
                  PARAM_LIST@40..49
                    L_PAREN@40..41 "("
                    PARAM@41..48
                      REF_TYPE@41..48
                        AMP@41..42 "&"
                        LIFETIME@42..44
                          LIFETIME_IDENT@42..44 "'a"
                        WHITESPACE@44..45 " "
                        PATH_TYPE@45..48
                          PATH@45..48
                            PATH_SEGMENT@45..48
                              NAME_REF@45..48
                                IDENT@45..48 "str"
                    R_PAREN@48..49 ")"
    WHITESPACE@49..50 "\n"
    BLOCK_EXPR@50..53
      L_CURLY@50..51 "{"
      WHITESPACE@51..52 " "
      R_CURLY@52..53 "}"
  WHITESPACE@53..54 "\n"

----

Diff:
----
SOURCE_FILE@0..54
  FN@0..53
    FN_KW@0..2 "fn"
    WHITESPACE@2..3 " "
    NAME@3..12
      IDENT@3..12 "for_trait"
    GENERIC_PARAM_LIST@12..15
      L_ANGLE@12..13 "<"
      TYPE_PARAM@13..14
        NAME@13..14
          IDENT@13..14 "F"
      R_ANGLE@14..15 ">"
    PARAM_LIST@15..17
      L_PAREN@15..16 "("
      R_PAREN@16..17 ")"
    WHITESPACE@17..18 "\n"
    WHERE_CLAUSE@18..49
      WHERE_KW@18..23 "where"
      WHITESPACE@23..27 "\n   "
      WHERE_PRED@27..49
        FOR_KW@27..30 "for"
        GENERIC_PARAM_LIST@30..34
          L_ANGLE@30..31 "<"
          LIFETIME_PARAM@31..33
            LIFETIME@31..33
              LIFETIME_IDENT@31..33 "\'a"
          R_ANGLE@33..34 ">"
        WHITESPACE@34..35 " "
        PATH_TYPE@35..36
          PATH@35..36
            PATH_SEGMENT@35..36
              NAME_REF@35..36
                IDENT@35..36 "F"
        COLON@36..37 ":"
        WHITESPACE@37..38 " "
        TYPE_BOUND_LIST@38..49
          TYPE_BOUND@38..49
            PATH_TYPE@38..49
              PATH@38..49
                PATH_SEGMENT@38..49
                  NAME_REF@38..40
                    IDENT@38..40 "Fn"
                  PARAM_LIST@40..49
                    L_PAREN@40..41 "("
                    PARAM@41..48
                      REF_TYPE@41..48
                        AMP@41..42 "&"
                        LIFETIME@42..44
                          LIFETIME_IDENT@42..44 "\'a"
                        WHITESPACE@44..45 " "
                        PATH_TYPE@45..48
                          PATH@45..48
                            PATH_SEGMENT@45..48
                              NAME_REF@45..48
                                IDENT@45..48 "str"
                    R_PAREN@48..49 ")"
    WHITESPACE@49..50 "\n"
    BLOCK_EXPR@50..53
      L_CURLY@50..51 "{"
      WHITESPACE@51..52 " "
      R_CURLY@52..53 "}"
  WHITESPACE@53..54 "\n"

----

failures:
    tests::lexer_tests
    tests::parser_tests

The debug output has changed in recent rust nightlies which causes that failure, I imagine your windows setup uses a recent nightly toolchain while your linux setup isnt

That's #8585.

bors r+
looks good to me, thanks!

authors: Veykril lnicola m5tfi matklad


text:
internal: ensure that client and server-side configs are not mixed up

bors r+
🤖

bors r+


text:
Release tracking PR: primitives 0.101.0

Its 00:02 on the 15th UTC now, I'm hoping this merges within 24 hours - then the date is correct.

Tagged and published.

Yes, awesome. Will be a proud user :)

authors: apoelstra storopoli tcharding

repo: rust-bitcoin/rust-bitcoin


text:
Rust MX meetup

Please help us by filling out the text below. All answers are optional
New Meetup
Where
Mexico City
The location you are running things in
What
We meet us in an office and talk about Rust and the tools made by it.

[ ] Learners Group
[x ] Meetup with talks
[ ] Conference/Camp

Links: https://www.meetup.com/es/Rust-MX/
When
The 3rd Wednesday of each month

[ ] I'd like the event to be on the public calendar
[x ] It's a repeating event, I would like to have access to the calender to do things on my own

Support

[ ] I need coaching or help to get started faster
[ ] I would like to be introduced to fellow meetup organizers in my area
[ x] I need help promoting

You can promote your event by advertising it on Twitter, Reddit and other channels. We understand that the breadth of this may be overwhelming for organizers and would offer to advertise the event for you. If you already have an active Twitter account and/or regularly announce your meetup through other channels you might not need this option.

[ ] I need additional help promoting my event

[x] I'd like to have swag (e.g. stickers)

If you're interested in obtaining stickers and/or swag, please send a short email to the community team, providing

Your physical mail address and phone number
The projected number of attendees for your event
How many events you're planning to run in the future
Optionally, if you're interested in a certain type of swag for specific reasons (e.g. you're running a T-Shirt give away)

CoC
The Rust project uses a Code of Conduct and we generally recommend you to as well. We also give advice on motivations and which one could be fitting for your project.

[x] We use a Code of Conduct
[ ] We need a recommendation for one

Contact details

[x] I filled out the form at https://docs.google.com/forms/d/e/1FAIpQLSf52YXGhqBaHtCXtVna4iHYMK7IQaTqUW6V-ztsZC8C2TBInQ/viewform and would like you to contact me with news.

Hey @mayela !
I'm closing this issue to clean up the repo, but if you have any thoughts or comments (or links/blogposts etc.) to share about how the event went we would be happy to hear about them!

authors: flaki mayela

repo: rust-community/events-team


text:
Rework the "where to go from here" section to track items we want to teach

This is part of the cleanup described in this issue:
https://github.com/rust-embedded/discovery/issues/231

r? @andre-richter
(rust_highfive has picked a reviewer for you, use r? to override)

bors r+

authors: jamesmunns rust-highfive therealprof

repo: rust-embedded/discovery


text:
feature request: cargo fuzz miri <target> to run all corpus items in miri

The use case here would be fuzzing some unsafe heavy code to find a corpus that should see a wide variety of inputs, then running the fuzzer, feeding each corpus item in turn to the fuzzer. This is useful since the fuzzer can't really notice rust specific UB if it doesn't happen to crash, but that's still UB that the user wants to know about.
This is not asking for fuzzing to be ran using miri (like #311), just running the fuzzer body once per corpus item. This is not exactly hard to do manually (refactor out the fuzzer body into a lib.rs, add a #[test] that reads each corpus item and feeds it to that, then run cargo miri test), but it's a bit of a pain.

Oh that's a clever idea. I'm in favor though don't have time to implement it myself.

Same

This is not exactly hard to do manually (refactor out the fuzzer body into a lib.rs, add a #[test] that reads each corpus item and feeds it to that, then run cargo miri test), but it's a bit of a pain.

I've had success with this approach and using rstest. Example:
#![cfg_attr(not(any(miri, test)), no_main)]

use libfuzzer_sys::{
    arbitrary::{self, Arbitrary, Unstructured},
    fuzz_target, Corpus,
};

#[derive(Debug, Arbitrary, Clone)]
struct Input {
    foo: usize,
    bar: Vec<u8>,
}

fuzz_target!(|input: Input| { run(input); });

fn run(input: Input) {
    // ...
}

#[cfg(test)]
mod tests {
    use crate::{run, Input};

    #[cfg(miri)]
    use {
        crate::{run, Input},
        libfuzzer_sys::arbitrary::{Arbitrary, Unstructured},
        rstest::rstest,
        std::{fs::File, io::Read, path::PathBuf},
    };

    #[rstest]
    #[cfg(miri)]
    fn miri(#[files("corpus/fuzz_corpus/*")] path: PathBuf) {
        let mut input = File::open(path).unwrap();
        let mut buf = Vec::new();
        input.read_to_end(&mut buf).unwrap();

        let mut unstructured = Unstructured::new(&buf);
        let input = Input::arbitrary(&mut unstructured).unwrap();
        run(input);
    }
}

Then cargo miri nextest run --bin [name of target] pretty much Just Works.
rstest composes well enough with this that I'm not sure it's worth code changes in cargo-fuzz? I suppose fuzz_target! could be extended to auto-generate this kind of code, but perhaps simpler is better. I'm happy to write up something in the fuzz book. Would that be acceptable @5225225 @Manishearth?
n.b. that Miri can have severe slowdowns if the code under test touches globals or thread local storage too much, so in those cases it may be better to shell out and invoke Miri separately for each entry in the corpus. Something to the tune of find corpus/target | parallel FILE={} cargo miri test --bin target miri. In which case the test would take the filename as an environment variable.

authors: 5225225 Manishearth fitzgen inahga

repo: rust-fuzz/cargo-fuzz


text:
Update hongfuzz to ~2.0 (current master)

fixes #30

Perfect!
Thanks @Mrmaxmeier for taking the time to do this PR :-)
bors r+

bors r+

authors: Mrmaxmeier PaulGrandperrin

repo: rust-fuzz/honggfuzz-rs


text:
September 2023 Meetup Registration

Happy September!
In preparation for the August Rust Gamedev Meetup, it will be taking place Saturday, the 16th of September! Note, this is a week after the normal meetup time
As always, I want to try and get some more work-in-progress projects shown off :) if it's not done, it would be awesome to see! Leave a comment with the template below to sign up 🚀
Template
Project:

Discord username:

Estimated time:

Streaming Logistics
We use StreamYard to host the meetup. Using it is quite similar to another browser video chat tool, like Google Meet. We'll do a tech test before the meetup, so you can become familiar with how it is used.

I'm excited for another update meetup 😳
Project: Blue Engine
Discord: elhamaryanpur
ETA: 10-15min

Sweet, glad it's back!
Graphite, ~15 minutes

@ElhamAryanpur with the updated date being this weekend, will you still be free?

Topic: no_std for game developers (or, for even if you're not working in embedded)
Discord: kpreid
Estimated time: 25 minutes

@AngelOnFira I'll be available d.w.

i am available

authors: AngelOnFira ElhamAryanpur Keavon cybersoulK kpreid

repo: rust-gamedev/meetup


text:
N50: sm64jsarchive (fixed)

Part of #1473

Thanks for the contribution! Two points!

The style checks are failing, but it seems easy to fix:

This seems to be a JS project. Could you elaborate on what this has to do with Rust?

Thanks for the contribution! Two points!
* The style checks are failing, but it seems easy to fix:
  ![image](https://private-user-images.githubusercontent.com/9047632/321236065-03d42837-e693-4c9f-b075-80adcec79480.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTI3NjUyNjgsIm5iZiI6MTcxMjc2NDk2OCwicGF0aCI6Ii85MDQ3NjMyLzMyMTIzNjA2NS0wM2Q0MjgzNy1lNjkzLTRjOWYtYjA3NS04MGFkY2VjNzk0ODAucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDQxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA0MTBUMTYwMjQ4WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTU3ZDNkZDczYjI0MmFhMGI1NjM2M2MzZWU4NDkyNjk5ZjQyZGFiMmIyYWFmMDAwMWFkOTQyZjQyMDNlOWM1ZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.Z91F9ZPnytYa8nFiFbqr2G7GUUA9YrwLdhk_FJzoY-c)

* This seems to be a JS project. Could you elaborate on what this has to do with Rust?

The backend is in rust also your check failed on the image part of it (sm64jsarchive.png) https://github.com/rust-gamedev/rust-gamedev.github.io/pull/1477/commits/9b4622637360b72d9eed9f22cf7fc7e0e190216d

@janhohenheim I tried fixing it please check again also I allowed edits by maintainers just incase.

Aah I see. Cool project!

@uuphoria2 I can fix the lints myself later if you are otherwise finished with the PR :)

@uuphoria2 I can fix the lints myself later if you are otherwise finished with the PR :)

That would be great if you can

@uuphoria2 I can fix the lints myself later if you are otherwise finished with the PR :)

Im running the rust servers for sm64jsarchive right now so note I might not be as active

@uuphoria2 I can fix the lints myself later if you are otherwise finished with the PR :)
Please do so, as I dont have much time to work on this pull request cuz im the only one maintaining the rust servers within docker for sm64jsarchive.

@uuphoria2 will do, just need some time myself. The newsletter will be sent out on the the 3rd of May, so there's no rush :)

Done now; thanks again for your submission!

Thank you so much.

I'll just note this to anybody viewing: The stress test already ended on april 10th tho im just here to tell how many people went on it: About 4-3 people and it was still really fun! :D

Thanks for the update, I'll make sure to update the info once the editorial period starts :)


text:
Add fn_return_indent = "Double"

If the return type has to be on a new line, I find it hard to read because the code has the same indention. Therefore, I'd like to have just a double indention in case it's on a new line. I cannot use
fn_return_indent = "WithArgs"

because my args are in "Block"-style.

For the RFC style we use block formatting and if there is return type we do not indent it at all so that it stands out. E.g.,
fn extract_one(
    &mut self,
    m: FxHashMap<PathBuf, PathKind>,
    flavor: CrateFlavor,
    slot: &mut Option<(Svh, MetadataBlob)>,
) -> Option<(PathBuf, PathKind)> {
    ...
}

authors: nrc torkleyy

repo: rust-lang-nursery/rustfmt


text:
[ci] enable clippy

Closes #110 .

I'm not sure that I want this, primarily because it targets Rust's unstable plugin API and is therefore prone to breakage. Case in point, this PR is failing because Clippy doesn't compile.
I also generally feel like most of the code in this crate is pretty simplistic, so the bang-to-buck ratio here isn't that great IMO.

I'm not sure that I want this, primarily because it targets Rust's unstable plugin API and is therefore prone to breakage. Case in point, this PR is failing because Clippy doesn't compile. I personally will get pretty annoyed pretty quickly if we can't merge PRs because of this.

Clippy is currently broken on nightly. I've added cargo clippy as the last test to be able to manually check if all other tests pass when clippy breaks. This should get better when clippy works with stable.
An alternative could be to add some extra builds to travis and appveyor to just run clippy. That way it is easy to see if clippy is broken, and we can still merge PRs.

I also generally feel like most of the code in this crate is pretty simplistic, so the bang-to-buck ratio here isn't that great IMO.

I've fixed some clippy errors locally but if I commit them would like to have somehow clippy enabled as a sanity test.

I'm personally not a huge fan and I feel like an "essentially auto generated" crate such as this probably won't benefit too much?

So I've fixed all the clippy warnings that I considered relevant, that is, some shifts by zero, a duplicated function in the runtime that felt through the code-review cracks, etc.
I've silenced all of the lints that do not apply to this library, but I've also silenced one lint that I cannot fix right now but we should probably improve on (missing_docs_in_private_items).
Now I hope that travis marks this as green and let me know what you think. IMO it did not found a lot of issues, but it found some beginner issues. I think that if this doesn't break CI all the time (I've put it in an allow_failure build) maybe we can just "try our bests" to keep it green.

@BurntSushi and @alexcrichton so I've documented all missing items and enabled the clippy lint. IMO PR's for intrinsics should require documentation.

I'm personally not a huge fan of all the #[allow] directives, but otherwise seems fine to me!

@alexcrichton me neither, AFAIK there isn't a way to specify which lints are allowed in the clippy.toml file. Not all lints apply to all projects, and I'd rather have them in a clippy.toml than in the lib.rs. Maybe I should file a clippy issue.

@llogiq any tips on how to set up clippy in CI ?

I assume you are on nightly already. So, you should be able to cargo install clippy -f && cargo clippy || true to allow failures (this means you'll need to look into the logs). You can deactivate lints via -A lint_name, but you need to precede cargo clippy's args with a double dash.
I personally don't think it makes much sense to even let a successful clippy run break the build at the moment. We are still adding more lints, so even when there is no breakage, every new clippy might uncover new warnings.

An advantage of the allow_failure approach is that you immediately see in the build matrix if there is any issue with clippy, while doing it in the way @llogiq proposes we would need to look into the logs of green builds for that. In both cases the travis build remains green if clippy either introduces new lints or cannot build, so we can just try to keep it green on a best effort basis.

@BurntSushi I will update this once the formatting commit is merged, hope we can merge this as well.

@alexcrichton I've rebased this :)

Looks like CI may be failing?

@alexcrichton done!

authors: BurntSushi alexcrichton gnzlbg llogiq

repo: rust-lang-nursery/stdsimd


text:
Poor interaction between workspace dependencies and default-features

Problem
Apologies in advance if this is categorized incorrectly, I can see how this could be either a bug or feature request.
Recently introduced to Cargo is the ability to specify dependencies at the workspace level. Crates within that workspace can specify their dependencies as { workspace = true }, which results in that crate inheriting the dependency from their parent workspace.
With respect to features the inheritance works in a purely additive way, which I believe works well in general, but not in the case of default features.
For example say you have a workspace with two crates, foo and bar, both of these crates depend on tracing. You want to make sure foo and bar depend on the same version of tracing, so you define it in your workspace and have crates inherit from it. In the crate bar you want to disable default-features for tracing, but you cannot since when you inherit from a workspace it's in a purely additive way. The only way to disable default-features in bar is to disable it at the workspace level, this has the adverse effect of also disabling default-features for foo. In the crate foo you could specify default-features = true, but this feels like an anti-pattern.
Scaling this example up a bit and you can better see how this is an issue. Say you have a workspace of 50 crates, 10 of which depend on tracing. In 1 of the 10 crates you want to disable default-features, to do that it requires you to specify default-features = true for the other 9, and any crates in the future that depend on tracing.
Steps

Create a new Rust project, make it a workspace, add a workspace.dependency of tracing = 0.1.37 (or any other crate).
Add a new crate foo, add a dependency of tracing = { workspace = true }.
Add a new crate bar, add a dependency of tracing = { workspace = true, default-features = false }.
Observe a compiler warning when building bar, indicating that the default-features flag is ignored.

Possible Solution(s)
Allow inherited dependencies within a workspace to disable default features.
Notes
No response
Version
$ cargo version --verbose
cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.2.0 [64-bit]

Note: I tried a workaround of specifying default-features = true at the workspace level, and then default-features = false within bar at the crate level. That did not produce a compiler warning but bar still depended on default features, specifying false at the crate level had no impact.

Thanks for the detailed report!
Totally understand the inconvenience. I am sorry for telling you that this is an intentional behavior for following the additive rule of Cargo features. Please see this table from this comment https://github.com/rust-lang/cargo/pull/11409#issuecomment-1374225756. Changing the behavior could lead to a breakage.
Besides the intentional design, do you feel anything can be documented better in this chapter in Cargo Guide?

Thanks for linking the comment! I had searched through the various PRs and RFCs to see if this was covered, I missed that one though 🙂
Could I propose changing the behavior then? What would be the right process for this, submitting an RFC maybe?
I totally understand that features within Cargo need to be additive, without this property any projects with a decent number of dependencies could fail to compile because the same crate could be depended on twice, but with conflicting feature sets, making the project impossible to compile. Because this additive property exists, having a crate opt out of a feature that the workspace enables should be entirely possible? In other words, it shouldn't cause any compilation issues? I don't believe the ability to generically opt out of a feature is needed, but without the ability to disable default features at the crate level, workspace inheritance is much less useful of a feature.
Recently I worked on migrating a decently large codebase to use workspace inheritance, https://github.com/MaterializeInc/materialize/pull/19375, but ran into this issue with default features. Without the ability to disable default-features at a crate level, I don't think we'll go through with this switch. Which is disappointing because having a single location to define all of our dependency versions would be super useful!
Thanks for chatting about this 🙂

FWIW, https://github.com/rust-lang/cargo/issues/3126 has more discussions about the future of default-features and some syntax to subtract a feature. Maybe this would help?
For proposing a change, I currently have no idea which route can fix this issue, as changing the behavior leads to another breakage. However, I think you can draft your idea here and if you can think of any transition to alleviate the potential breakage, please include them!

I've had a growing feeling that being able to inherit things besides dependency sources was a mistake.  Rarely do implementation requirements mean every package needs the same set of features, optional, public, etc.  Instead, they diverge.  The one exception is workspace hacks but workspace.dependencies alone is insufficient to support that.
If I felt confident enough in this stance, we could move to only allow inheriting source information in the next Edition (the wording is so that the package's Edition is in control since workspaces don't have an Edition).  However, I am not confident enough at this time to move in that direction.
People can do it themselves (or with the help of a clippy lint) except for this issue.
I wonder if what we could do on an Edition boundary is to make it so that the lack of default-features in workspace.dependencies doesn't apply the default when inheriting but is ignored.
@Muscraft thoughts?

We talked about this in today's cargo team meeting.
Its a bit unclear if we'd want to go the full way and deprecate features, default-features in workspace.dependencies, removing them in an Edition.

We gave users a tool and might be hard to claw it back, even if its "correct"
We theorize most uses are for implementation focused and not requirements focused but its hard to say for sure

If we want to consider that, likely the best route is a short-term solution to this issue with a lint to discourage default-features / features.  If the lint were in an opinionated linter like clippy, it could even be warn by default one day (ie be promoted from pedantic to style).  Whether its allow or warn by default, we could search github to see how much it is used (while recognizing the bias that open source might be doing things differently than corporate).
For a short-term solution, it would likely be to make default-features in a workspace.dependencies be a Option<bool> where the None case means "unset" (compared to today where its "true")
One concern with this short-term route is that is isn't  as consistent in behavior across cargo.  If we deprecated default-features / features, then we would become consistent again, but instead of being consistent with dependencies, it would be patch.  However, sometimes user expectations don't favor consistency and the more intuitive route is inconsistent.  Maybe this is one of those cases.
We do need to recognize the cost of ecosystem churn with any of this.  This would be a subtle behavior change that people would need to migrate through, both in code and in education.  We'd also need to make the docs more complicated to cover the cases for each Edition.

To summarize the proposal, quoting from @Muscraft  who built this on top of the work of @ehuss in #11409

Workspace
Member
1.64 behaviour
1.69 behavior
proposed 202X Edition behavior
Reasoning

nothing
df=false
Enabled
Enabled, warning that it is ignored
Disabled
Basically means let the package control default features when not specified

df=true
df=false
Enabled
Enabled, warning
Enabled, warning
Should have been an error in the past since the field is ignored. May change to an error in the future.

nothing
df=true
Enabled
Enabled
Enabled
There is no conflict about default being enabled.

df=true
df=true
Enabled
Enabled
Enabled
^Same

nothing
nothing
Enabled
Enabled
Enabled
No ambiguity.

df=true
nothing
Enabled
Enabled
Enabled
Enabled

df=false
df=false
Disabled
Disabled
Disabled
No ambiguity.

df=false
df=true
Disabled
Enabled
Enabled
This allows members to decide whether or not they want default features. The workaround of features=["default"] seems unnecessary.

df=false
df=nothing
Disabled
Disabled
Disabled
Natural way to write "give me whatever was written in workspace".

The proposal looks good to me @epage.
I'd prefer an error in scenario no. 2, since we have the freedom to do that at an edition boundary.

Hey @epage, thanks for reconsidering this! The behavior table you listed above makes sense to me and fixes the original concerns I had.
FWIW I also like the idea that workspace dependencies should only be able to inherit source information, but I think the correct long term solution is a lint guiding users away from it, instead of disallowing it entirely. An example of where it would be nice to inherit features from the workspace is when it's a performance related feature, e.g. smallvec's union feature. You might want to enable union for all uses of smallvec in your workspace, and workspace dependencies seems like the right tool for that. All of this to say, if a lint is created it would be nice if users could exclude specific crates.

I'd prefer an error in scenario no. 2, since we have the freedom to do that at an edition boundary.

I left that out because its being talked about as part of #13629

A way to reframe this: instead of merging a package dependency into a workspace dependency, keeping the workspace dependency's defaults, we could switch to merging a workspace dependency into a package dependency, keeping the package dependency's defaults.

authors: LukeMathWalker ParkMyCar epage weihanglo

repo: rust-lang/cargo


text:
Non determinist vendoring of git dependencies

Problem
The output of cargo vendor is not determinist for git dependencies. Depending on the machine where the command is executed, the Cargo.toml of the vendored dependencies can be different. All tests were done on various versions of Ubuntu but with the same version of cargo. The difference is only about order of arrays of tables in the Cargo.toml.
I made a minimal reproduction example in this repo for which I ran the vendor command on my computer. You can see in this CI run that running cargo vendor results in a diff with master. Also, the diff is not the same between the 3 jobs, so it doesn't seems like a mistake on my part.
Steps
No response
Possible Solution(s)
I'm not very familiar with the cargo codebase, but after digging a bit, it seems to only happen with git dependencies because they are treated differently. Those dependencies are not published on crates.io so their Cargo.toml is not normalised. Due to this, the Cargo.toml is normalised before the copy to the vendor directory. This normalisation yields different results depending on the machine.
Notes
No response
Version
cargo 1.80.0-nightly (431db31d0 2024-05-28)
release: 1.80.0-nightly
commit-hash: 431db31d0dbeda320caf8ef8535ea48eb3093407
commit-date: 2024-05-28
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 22.4.0 (jammy) [64-bit]

From the CI log:
 diff --git a/vendor/axum-server/Cargo.toml b/vendor/axum-server/Cargo.toml
index 21eb1f1..fe22018 100644
--- a/vendor/axum-server/Cargo.toml
+++ b/vendor/axum-server/Cargo.toml
@@ -89,28 +89,28 @@ doc-scrape-examples = true
 required-features = ["tls-rustls"]

 [[example]]
-name = "shutdown"
-path = "examples/shutdown.rs"
+name = "graceful_shutdown"
+path = "examples/graceful_shutdown.rs"

 [[example]]
 name = "remote_address"
 path = "examples/remote_address.rs"

 [[example]]
-name = "from_std_listener"
-path = "examples/from_std_listener.rs"
+name = "multiple_addresses"
+path = "examples/multiple_addresses.rs"

 [[example]]
-name = "graceful_shutdown"
-path = "examples/graceful_shutdown.rs"
+name = "shutdown"
+path = "examples/shutdown.rs"

 [[example]]
-name = "hello_world"
-path = "examples/hello_world.rs"
+name = "from_std_listener"
+path = "examples/from_std_listener.rs"

 [[example]]
-name = "multiple_addresses"
-path = "examples/multiple_addresses.rs"
+name = "hello_world"
+path = "examples/hello_world.rs"

 [[example]]
 name = "remote_address_using_tower"

In #13713, we resolve all implicit targets.  Those aren't being done in a deterministic order, causing each run to be different.

Sorry to revive this issue, but I updated the toolchain of the reproduction example and the problem is still there.
What I did to test

Update rust-toolchain.toml file to use newer nightly containing your commit (checked with cargo version --verbose)
Clean my local cargo cache of downloaded dependencies
Delete .cargo/config.toml and the vendor directory
Ran cargo vendor > .cargo/config.toml

On my computer, the vendor directory was the same as the remote repository, so no changes to commit. Also, the diff is still different between the 3 jobs.

What nightly did you try this on? We need to verify that it had the fix.
Also, did you update the vendored packages with that nightly before checking for consistency?

Also, can you include a copy of a failed?

cargo version --verbose on my computer :
cargo 1.80.0-nightly (7a6fad098 2024-05-31)
release: 1.80.0-nightly
commit-hash: 7a6fad0984d28c8330974636972aa296b67c4513
commit-date: 2024-05-31
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 22.4.0 (jammy) [64-bit]

cargo version --verbose on the CI :
cargo 1.80.0-nightly (7a6fad098 2024-05-31)
release: 1.80.0-nightly
commit-hash: 7a6fad0984d28c8330974636972aa296b67c4513
commit-date: 2024-05-31
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 24.4.0 (noble) [64-bit]

Diff on the 24.04 runner :
diff --git a/vendor/axum-server/Cargo.toml b/vendor/axum-server/Cargo.toml
index 21eb1f1..fe22018 100644
--- a/vendor/axum-server/Cargo.toml
+++ b/vendor/axum-server/Cargo.toml
@@ -89,28 +89,28 @@ doc-scrape-examples = true
 required-features = ["tls-rustls"]

 [[example]]
-name = "shutdown"
-path = "examples/shutdown.rs"
+name = "graceful_shutdown"
+path = "examples/graceful_shutdown.rs"

 [[example]]
 name = "remote_address"
 path = "examples/remote_address.rs"

 [[example]]
-name = "from_std_listener"
-path = "examples/from_std_listener.rs"
+name = "multiple_addresses"
+path = "examples/multiple_addresses.rs"

 [[example]]
-name = "graceful_shutdown"
-path = "examples/graceful_shutdown.rs"
+name = "shutdown"
+path = "examples/shutdown.rs"

 [[example]]
-name = "hello_world"
-path = "examples/hello_world.rs"
+name = "from_std_listener"
+path = "examples/from_std_listener.rs"

 [[example]]
-name = "multiple_addresses"
-path = "examples/multiple_addresses.rs"
+name = "hello_world"
+path = "examples/hello_world.rs"

 [[example]]
 name = "remote_address_using_tower"

Diff on the 22.04 runner :
diff --git a/vendor/axum-server/Cargo.toml b/vendor/axum-server/Cargo.toml
index 21eb1f1..2255a52 100644
--- a/vendor/axum-server/Cargo.toml
+++ b/vendor/axum-server/Cargo.toml
@@ -89,13 +89,21 @@ doc-scrape-examples = true
 required-features = ["tls-rustls"]

 [[example]]
-name = "shutdown"
-path = "examples/shutdown.rs"
+name = "multiple_addresses"
+path = "examples/multiple_addresses.rs"
+
+[[example]]
+name = "hello_world"
+path = "examples/hello_world.rs"

 [[example]]
 name = "remote_address"
 path = "examples/remote_address.rs"

+[[example]]
+name = "shutdown"
+path = "examples/shutdown.rs"
+
 [[example]]
 name = "from_std_listener"
 path = "examples/from_std_listener.rs"
@@ -104,14 +112,6 @@ path = "examples/from_std_listener.rs"
 name = "graceful_shutdown"
 path = "examples/graceful_shutdown.rs"

-[[example]]
-name = "hello_world"
-path = "examples/hello_world.rs"
-
-[[example]]
-name = "multiple_addresses"
-path = "examples/multiple_addresses.rs"
-
 [[example]]
 name = "remote_address_using_tower"
 path = "examples/remote_address_using_tower.rs"

Well, I don't know why but :
$ cargo +nightly-2024-06-03 version --verbose
cargo 1.80.0-nightly (7a6fad098 2024-05-31)
release: 1.80.0-nightly
commit-hash: 7a6fad0984d28c8330974636972aa296b67c4513
commit-date: 2024-05-31
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 22.4.0 (jammy) [64-bit]

The commit 7a6fad0984d28c8330974636972aa296b67c4513 of the used cargo is newer than your commit 40b9fec2550161c3ca257e04b9e6a2b13cef09c8 so your fix should be present.

The prepare_toml_for_publish function doesn't seem to be called when vendoring git dependencies, but maybe I'm missing something. After a bit more digging, the non determinism when vendoring git dependencies could come from either one of these :

The download could fetch the file differently depending on the machine but this would be weird
The deserialization, serialization or resolution of the Cargo.toml which is done locally when vendoring those kind of dependencies

Looks like I sorted too late in the process.  I had assumed we had tests and they happened to be sorted but it doesn't look like we have them.  I have a follow up I'm about to post.

authors: epage stormshield-guillaumed


text:
cargo test don't work in macos and doesn't detect my tests

Problem
when running cargo test --all doesn't detect tests.
Steps
write a test file.

#[cfg(test)]
mod tests {

    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}

run cargo test .
but cargo won't recognize my tests.
also i ran cargo test <file_test.rs> .
but rustc --test <file_test.rs> ; ./<file_test>  will work!

Can you include the output that you got from cargo?
cargo test doesn't accept filenames.  You need to set up a package which has a particular layout.

cargo test normally runs, but it doesn't detect any test case.
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running /Users/macuser/Documents/GitHub/BIIIIIIIIIIIIIG/target/debug/deps/big-946bdd8dd498cc60

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

link

I don't see any functions marked with #[test] in the repo you linked.

sorry @ehuss , it's conflicted by nightly and racer .

authors: Arshiamidos ehuss


text:
help: display external subcommand help

When invoking cargo help <subcommand>, if the subcommand isn't found, but it is an external subcommand, call that subcommand with --help.
A test should probably be written for this, but I'm not sure how best to mock an external subcommand.

Thanks for the PR! I think you should be able to emulate a custom subcommand similar to install.rs how custom subcommands are installed?

@alexcrichton Added test.

LGTM!
@alexcrichton anything else to add?

@bors: r+

:pushpin: Commit dca0db2dce22494ac03f825065fafa5fa6b6d94a has been approved by alexcrichton

:hourglass: Testing commit dca0db2dce22494ac03f825065fafa5fa6b6d94a with merge 738c42d4dc91f916ddc353f23f7ae9ff2cf5452c...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 738c42d4dc91f916ddc353f23f7ae9ff2cf5452c to master...

authors: alexcrichton bors euclio matklad


text:
Fix broken link in docs.rs

Fixed #1172

cc @ChrisDenton can you take a look at this please?
There're some broken links in our docs.rs, on how to build on windows.

repo: rust-lang/cc-rs


text:
Improve formatting of rustwide log messages

Enables tracing-subscriber/tracing-log feature to get its support for formatting based on these messages custom attributes, requires a workaround during registration to ignore the failure of tracing-subscriber to register its own tracing-log instance as we've already registered one through rustwide.
fixes #2336
It's a bit hacky, and relies on the order that try_init registers the different components
https://github.com/tokio-rs/tracing/blob/8ba80ae82371638aa749436e4f284b65adf9ff90/tracing-subscriber/src/util.rs#L58-L74

There's a better way to do this by registering the tracing logger manually instead of using the try_init method, but I can't set to draft status from mobile.

Updated to use the direct registration APIs instead of the tracing-subscriber helpers.


text:
Define DT_UNKNOWN on Fuchsia.

It looks like this constant is relied on in the new remove_dir_all logic and we need to reference it to be able to use the CVE fix correctly on Fuchsia.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon.
Please see the contribution instructions for more information.

@bors r+

:pushpin: Commit af308591bdb98682a345d78da4163773eb6dbd01 has been approved by Amanieu

:hourglass: Testing commit af308591bdb98682a345d78da4163773eb6dbd01 with merge 3063aa1b45ea81b623af19b3eb9ba9c43619b23c...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing 3063aa1b45ea81b623af19b3eb9ba9c43619b23c to master...

authors: Amanieu anp bors rust-highfive

repo: rust-lang/libc


text:
Update the virtual clock in isolation mode to step forward with around the same speed as the host system.

Before this, the 1s sleep test took around 4 minutes on my machine.

r=me with "some sample programs" made a bit less vague.

@bors r=RalfJung

:pushpin: Commit 16eb6980e3ad3001fde2f4601522953f34b67d3a has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit 16eb6980e3ad3001fde2f4601522953f34b67d3a with merge d20acaf002261844aa2cf6fed96abe19d26b7a57...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing d20acaf002261844aa2cf6fed96abe19d26b7a57 to master...

authors: RalfJung bors oli-obk

repo: rust-lang/miri


text:
Allow removing a component

This implement the possibility of removing a component from a toolchain.
Fixes #19.

This needs to be rebased over the latest master, otherwise it looks good!

Done.

Thanks!

Released rustwide 0.9.0 with this change!

Great !

authors: kellda pietroalbini

repo: rust-lang/rustwide


text:
Add verbose flag to print cargo commands

I often find myself wanting to reproduce the same command that cargo-3ds was running, so I thought it would be handy to print these commands out when a flag is passed in.
The output looks like this, with the intention that it can be copy-pasted back into the shell easily to run the same command:
$ cargo 3ds -v test
No pre-build std found, using build-std
Running command:
   RUSTDOCFLAGS=" --no-run --persist-doctests target/doctests" \
   RUSTFLAGS=" -L/opt/devkitpro/libctru/lib -lctru" \
   /Users/ianchamberlain/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/cargo test --target armv6k-nintendo-3ds --message-format json-render-diagnostics -Z build-std --no-run

    Finished test [unoptimized + debuginfo] target(s) in 0.26s
Getting metadata
Building smdh:/Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.smdh
Running command:
   smdhtool --create integration "Homebrew Application" "Unspecified Author" /opt/devkitpro/libctru/default_icon.png /Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.smdh

Building 3dsx: /Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.3dsx
Running command:
   3dsxtool /Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.elf /Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.3dsx "--smdh=/Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.smdh"

Running 3dslink
Running command:
   3dslink /Users/ianchamberlain/Documents/Development/3ds/test-runner-3ds/target/armv6k-nintendo-3ds/debug/deps/integration-86fc0175e918598b.3dsx

No response from 3DS!

Also fix minor issue with building test crate for doctests.

This is a very welcome addition, especially since cargo-3ds presents a film of obscurity between the user and the commands actually run (maybe we should do something about documenting how cargo-3ds interacts with the environment).
Just a thing: even though I think that it'd be almost impossible to move away from 3dslink (especially for how it interacts with the Homebrew Menu), I would still like to work on #2. What do you think about moving away from console commands and actually re-implement some features?

Just a thing: even though I think that it'd be almost impossible to move away from 3dslink (especially for how it interacts with the Homebrew Menu), I would still like to work on #2. What do you think about moving away from console commands and actually re-implement some features?

Sure, I don't think it's a bad idea, if you want to. I personally wouldn't consider it a priority, since users will always have to have the toolchain installed anyway, so we should always be able to rely on the existence of those tools. Having more stuff in Rust (and library-usable) is always nice though!

Going to go ahead and merge this, it fixes some issues with building doctests and doesn't seem too controversial.

authors: Meziu ian-h-chamberlain


text:
Updated Glam to 0.22 and other minor improvements

Hello! This PR adds:

glam updated form 0.21 to 0.22.
Update Cargo.toml rust edition from 2018 to 2021.
Fixes all clippy lint warnings.

This change is

Changes made, thanks!

Awesome, thanks!

Hey @zakarumych I just realized that is not on crate.io yet. It would be awesome to have it there, however, I have no rush. Thanks!

Ping! Hey @zakarumych is it possible to publish the latest version to crates.io? Thanks!

Sure. Done!

Thank you so much!

authors: Nazariglez zakarumych

repo: rustgd/glsl-layout


text:
mutable  obj  show warm

Describe the Bug
when obj need to mut is show err that his obj is not mut

This isn't a bug.
Since the latest version of web-sys, new setter methods were introduced, which you are already using here, that don't need mutable access.

This isn't a bug. Since the latest version of web-sys, new setter methods were introduced, which you are already using here, that don't need mutable access.

@daxpedda if am not set it to mut it not modify the obj :/
and it show warn on rust runtime checker

@daxpedda if am not set it to mut it not modify the obj :/

That doesn't sound right, but seems like a Rust problem to me and not a wasm-bindgen one.
I'm happy to take a bit of deeper look if you can share a minimal example of the problem you are encountering.

@daxpedda if am not set it to mut it not modify the obj :/

That doesn't sound right, but seems like a Rust problem to me and not a wasm-bindgen one.
I'm happy to take a bit of deeper look if you can share a minimal example of the problem you are encountering.

@daxpedda Sorry I think I fix it by updating the version

authors: daxpedda thedtvn

repo: rustwasm/wasm-bindgen


text:
Add namespace and function to .d.ts file when in --no-modules mode

I tried using the TS declaration file in the --no-modules mode. Example:
#[wasm_bindgen]
pub fn get_color(x: u8, y: u8) -> Color {
    Color { r: x, g: y, b: 0 }
}

#[wasm_bindgen]
pub struct Color {
    pub r: u8,
    pub g: u8,
    pub b: u8,
}

Results in this file:
/* tslint:disable */
export function get_color(arg0: number, arg1: number): Color;

export class Color {
r: number
g: number
b: number
free(): void;
}

But since this isn't a module anymore, I can't import it in my TS file via import ...;. Instead, I think, the correct was is to use namespaces. If I modify the file from above:
declare namespace wasm_bindgen {
    /* tslint:disable */
    export function get_color(arg0: number, arg1: number): Color;

    export class Color {
    r: number
    g: number
    b: number
    free(): void;
    }
}

declare function wasm_bindgen(path: string): Promise<void>;

I can simply place this modified file next to my real TS file and it works (as in I can call wasm_bindgen("foo") and wasm_bindgen.get_color()).
Currently, I use a build script to apply these modifications to the file emitted by wasm-bindgen. But I think this is what wasm-bindgen should always emit in --no-modules mode, right? But if I'm wrong somewhere (which could very well be), please just tell me ^_^

Thanks for the report! I definitely agree that --no-modules emits broken TS, and it'd be great to fix!
Would you like to send a PR for this?

@alexcrichton I'm not sure if I'll find time to work on this. But regardless: could you maybe list the main files and functions involved in generating the TS declarations? Knowing where to start looking makes it way easier to start working on this -- for me or anyone else :)

Sure! Almost all the JS generation happens here. Right now the typescript field of the context builds up the Typescript that's generated. It's all a bit of a mess in the sense that it's not too structured, but it shouldn't be to hard to add some structures and postprocessing around there

For those who are looking around for a way how to load a wasm-bindgen-generated module from a worker. Following code at least just works anyway.
// main.js
const worker = new Worker("worker.js");

// worker.js
// Assume that your crate is named "foo" and it exposes a function named "bar".
var wasm_bindgen: typeof import("path/to/pkg") &
  typeof import("path/to/pkg").default;
self.importScripts("path/to/pkg/foo.js");
self
  .wasm_bindgen("path/to/pkg/foo_bg.wasm")
  .then(() => {
    self.wasm_bindgen.bar();
  });

@alexcrichton I tried to get something up for this but I'm not really sure how to fully verify. Is there somewhere I can go to get info on how to roll changes to this repo into a CLI command (like wasm-pack) so I can see the *.d.ts changes? Also, is there any guidance on setting up automated tests? (Especially: are there tests that I could copy that verify a TypeScript instance can compile the *.d.ts files?)

There's tests in crates/typescript-tests in this repository, and there are some reference output tests in crates/cli/tests, although I don't think that the typescript is tested there. Otherwise if CI passes you should be good to go!

@alexcrichton Ok. I somewhat lost track of this. Is there a way to test passing in some Rust with the usual #[wasm_bindgen] + the --no-modules argument and seeing the resulting TypeScript? I think the automated tests otherwise passed locally.

authors: LukasKalbertodt aaron-human alexcrichton mizkichan