https://fasterthanli.me/articles/so-you-want-to-live-reload-rust maybe related? We could even hot reload the whole application.

Yes, it's still there. Steps to reproduce (I use firefox on mobile):

1. go to search page
2. type something to search
3. blue the search (keyboard lowers)
4. you cannot click on search bar anymore

Oh, I just found out that it work except the click position is way out, you need to touch the corner of the screen rather than the center of the box itself.

Okay, this pull request does not fix the issue I mentioned.

That seems like it's a separate bug to fix. Does that mean you can't search at all on mobile?

No, you can search exactly once but not more than that. Once you searched, you need to go back and come back or reload the page IIRC.

IIRC in the mobile you cannot even open the keyboard if the search bar is not focused in the first place, I thought the patch is a fix for it.

@hosseind75 I am also a bit now on this but my guess is that this is probably not a very easy task to begin with.

Or maybe check in compiler/rustc_parse/src/parser/expr.rs or somewhere around there? My guess is somewhere around parse_lit but maybe @estebank can give you a more detailed mentor instructions.

Uh, why are you doing a dozen PRs to make tiny changes to my specialization PR? You could have reviewed it when it was open for months, then I could have finished it immediately worried

Yeah, I wonder why all my PRs is related to your PR. I wish it could reviewed it last time but probably I missed it, by the time I saw it it was already merged. Since I was copying word by word on vec for one of my project so I easily noticed the typos. Feel free to ping to regarding vec next time, at least I don't need to send so many PRs.

I would be interested to see a comparison with vue 3 release too.

Iced is built from scratch to support multiple platforms, how is sauron-native compared to it?

thread the write pointer through its innards

mem::ManuallyDrop::new -> ManuallyDrop::new

Is this even valid? Looks weird to me.

cc @the8472

Nice but wouldn't rust release indicate that all of the other packages released?

I wonder if Applicability::MaybeIncorrect should have a Display or some sort to convert to text. Still likely feels weird, I see another alternative is probably which may be a bit better (my two cents).

@estebank Can you please help to review again?

@pickfire change once instead of [0].iter() after this.

@rustbot modify labels: +C-cleanup +A-testsuite

Move LEN so it is is read in order.

Another approach would be to ship automatically generated manpages as fish will parse those as well.

Kubectl man pages is neither human readable nor fish-manpage-completions parsable.

I use https://gist.github.com/terlar/28e1c2e4ac9a27be7a5950306bf45ab2 in the meantime.

// this program is not technically incorrect, but is an obscure enough style to be worth linting
#![deny(temporary_cstring_as_ptr)]

use std::ffi::CString;

fn main() {
    let s = CString::new("some text").unwrap().as_ptr();
    //~^ ERROR getting the inner pointer of a temporary `CString`

Why not just remove the ignore tidy linelength check and reduce this line length?

    some_function(CString::new("").unwrap().as_ptr());
    //~^ ERROR getting the inner pointer of a temporary `CString`

Is this necessary?

cc @fafhrd91 who may be interested in this

Shouldn't it return EOF error when this happens?

Conditional documentation?

Why not just pop without the checks?

A better choice may be to change the naming to reflect that it does not include the new lines, at least that could solve the problem with naming inconsistency.

But if we keep the line, then people would need to fallback to trim which currently does not return a String in place but &str.

Can it commit partially?

Yes, that's where it moved but I don't understand why. Do you have any idea?

not sure about inject but it was written in doc there.

I don't know where that comes from either...

Maybe we should remove it?

Oh no, how come I broke some other parts? T_T

I think we could also remove the lossy_unicode since it is always allocating a String, we don't need that when we do only format! for those usage, I use String::from_utf8_lossy(s.as_bytes()) instead.

Oh, you are correct. We need to run it since it was not runned for the other parts of the description.

If I am correct, we already run lossy_unicode when we first loads the file so I think it is unnecessary to do it again. I think it was also called above but I think that could also be removed.

Oh, I took it from upstream python but I forgot to update the tests. I was wondering why upstream python does not have the trailing . and noticed that ours is probably a bit old. I fixed the behavior to only remove the last period rather than the first one.

@sHaDoW-54 Can you please move the latest changes in stdio to a second pull request? Also, I wonder why the tests was removed (can comment on the other pull request). At least we can keep this pull request only to std::io::input so reviewing can be easier.

Oh, I forgot about it, [^.] matches the previous character which .* should match. Thanks for the explanation @Screwtapello @krobelus

One benefit is that you'll know precisely when you actually have IME, so you won't call to set_ime_position until you've got an event from a winit that IME was enabled for some window.

Based on my experience with xinput on X11, I believe it is good to be able to call set_ime_position when the IME was enabled rather than updating it for every key press or some weird solution to make some timer to update it once it a while.

Maybe off-topic, I just wonder if I should create a new issue (or I am lazy).

/// Hello
/// world.

Should be formatted as

/// Hello world.

But if the sentence already ends.

/// Hello.
/// World.

Then it should be the same. Other languages may need to be checked as well.

Based on rust.kak Fix #421

<!--

Hi, and thanks for reporting an issue with rust.vim.

Details about your environment will help us assist you.

Please edit this template!

-->

• rust.vim version: 96e79e3 <!-- Describe if you use a Vim plugin manager, and you can use it to tell which version of rust.vim you are running. -->

Steps to reproduce:

<!-- It's best to try to reproduce the issue with the master version of rust.vim. The issue may already be fixed! -->

for (_z, group) in rendering_batches
    .iter()
    .sorted_by(|a, b| Ord::cmp(&a.0, &b.0))

Press o and {, the curly braces does not dedent. I noticed this issue when improving kakoune vim indentation recently https://github.com/mawww/kakoune/pull/3767

Relevant test at https://github.com/mawww/kakoune/pull/3767/files#diff-a5e6f076e466bf49de7e8d7bb2826d81R43

Expected vs. actual behavior:

for (_z, group) in rendering_batches
    .iter()
    .sorted_by(|a, b| Ord::cmp(&a.0, &b.0))
{

for (_z, group) in rendering_batches
    .iter()
    .sorted_by(|a, b| Ord::cmp(&a.0, &b.0))
    {

Paste debugging info from the Rust Vim plugin via one of the following commands: :RustInfo, :RustInfoToClipboard, or :RustInfoToFile <filename>.

rust.vim Global Variables:

let g:ftplugin_rust_source_path = v:null let g:loaded_syntastic_rust_cargo_checker = v:null let g:loaded_syntastic_rust_filetype = v:null let g:loaded_syntastic_rust_rustc_checker = v:null let g:rust_bang_comment_leader = v:null let g:rust_cargo_avoid_whole_workspace = v:null let g:rust_clip_command = v:null let g:rust_conceal = v:null let g:rust_conceal_mod_path = v:null let g:rust_conceal_pub = v:null let g:rust_fold = v:null let g:rust_last_args = v:null let b:rust_last_args = [] let g:rust_last_rustc_args = v:null let b:rust_last_rustc_args = [] let g:rust_original_delimitMate_excluded_regions = v:null let g:rust_playpen_url = v:null let g:rust_prev_delimitMate_quotes = v:null let g:rust_recent_nearest_cargo_tol = v:null let g:rust_recent_root_cargo_toml = v:null let g:rust_recommended_style = v:null let g:rust_set_conceallevel = v:null let g:rust_set_conceallevel=1 = v:null let g:rust_set_foldmethod = v:null let g:rust_set_foldmethod=1 = v:null let g:rust_shortener_url = v:null let g:rustc_makeprg_no_percent = v:null let g:rustc_path = v:null let g:rustfmt_autosave = 0 let g:rustfmt_autosave_if_config_present = v:null let g:rustfmt_command = 'rustfmt' let g:rustfmt_emit_files = 1 let g:rustfmt_fail_silently = 0 let g:rustfmt_options = '' let g:syntastic_extra_filetypes = ['rust'] let g:syntastic_rust_cargo_fname = v:null rustfmt 1.4.21-nightly (01f2ead 2020-09-04)

rustc 1.48.0-nightly (043f6d747 2020-09-25)

cargo 1.48.0-nightly (8777a6b1e 2020-09-15)

NVIM v0.4.4 Build type: Release LuaJIT 2.0.5 Compilation: /usr/bin/cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.4/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include Compiled by builduser

Features: +acl +iconv +tui See ":help feature-compile"

system vimrc file: "$VIM/sysinit.vim" fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Steps <!-- how to reproduce the issue? -->

1. Insert " .a" (there are some spaces, insert without quote)
2. alt-k ^\h*[^.] <ret>

Outcome <!-- what is the result of the above steps? -->

It was selected.

Expected <!-- what should have been the result of the above steps? -->

It should not be selected.

However, if \h in not used, it works. Workaround, s [^h].* <ret> and then only use ^ instead of ^\h*.

The first one works fine, because the <a-k> regex does not need to match the enitre selection, only a substring.

Ah, I didn't know about that. I though tit needs to match the entire selection.

Okay, I was actually matching the whole string but I thought echo ' .' | kak -f '<a-k>^\h*[^.]<ret>' should fail since it did not match the [^.] part which I think it should, weird that it does not, I still don't get why.

What I was trying out was:

$ echo ' + 1' | kak -f '<a-k>^\h*[^.+-].*[^\h].*[^,<semicolon>]$<ret>'
 + 1

But I guess I have some issues with the regex. Then I created one with a more complex kak script.

try %< execute-keys -draft k <a-x> s [^\h].+ <ret> <a-K> \A[-+*/&|^})<gt><lt>] <ret> <a-K> [,<semicolon>](\h*/[/*].*|)$ <ret> j <a-gt> >

Nevermind, I guess I can just keep the s rather than using <a-k>.

Thanks for clarifying.

The cost is not complexity, it's that it will break lots of existing code.

Then could this be part of a major release since it is a breaking change? I mean it is a breaking change since it should not allow broken type in the first place, I know it is hard since it may be hard to not use Any type but rely only on features available in the rust compiler.

Runtime type check is safe.

Yes, it is safe. But since I saw actix-web keep putting post to remove the use of unsafe but why not remove foot guns which affects the users? Even other languages like python is safe, I believe it would be a great deal breaker to use a library that does not have foot gun here and there, I personally prefer rust over python due to less runtime error.

There is no such thing called "if it compiles, it works", at least not for Rust. You need a lot of tests and even with those you would still get thing wrong here and there.

It is almost there, I mean excluding logic errors. At least one does not need to invoke a debugger to check out what is wrong. I never said to skip test but for quick prototyping, it would still be better for the compiler to warn me what is wrong rather than having to cargo run (and here requires another curl to check if the data extractor is working) instead of just cargo check (most online articles mention that this is enough, I also personally found this very sufficient frequently).

At first, I wonder if this is feasible or not, but now I know that you built a prototype means it is working, I thought it may not be possible to do so. So now at least I know that there is a breaking change but not as bad as I thought it would, like harming the ergonomics or performance or having extra complexity.

I mean as in [^.] should fail when matching the period since it negate that out, using it directly works but not with ^\h*.

Before

foo%( )

foo
.bar

After

foo%( )

foo
    .bar

For operation c bar. I put checks on operators like ., and even those - or &&.

TLDR: A static typed state would break all middlewares and all type extractors. ResponseBuilder would also require extra type signature. Too much of a price to pay and the gain is little in comparison.

But the price is not a runtime-cost but however the current one not only incur some runtime cost for data type lookup in hashmap but also results in safety cost, if that part of code was not tested it might suddenly just break, it does not have the safety rust provides such that "if it compiles, it works".

No, I mean negation as in [^.] in the regex, not <kbd>a-k</kbd>.

Steps <!-- how to reproduce the issue? -->

1. Insert " .a" (there are some spaces, insert without quote)
2. alt-k ^\h*[^.] <ret>

Outcome <!-- what is the result of the above steps? -->

It was selected.

Expected <!-- what should have been the result of the above steps? -->

It should not be selected.

However, if \h in not used, it works. Workaround, s [^h].* <ret> and then only use ^ instead of ^\h*.

How about this?

    fn from_iter(iterator: IntoIter<T>) -> Self {
        // It is common to pass a vector to a function which immediately
        // re-collects as a vector. We can short circuit this behavior if
        // the IntoIter has not been advanced.
        //
        // We reuse the original buffer if the iterator has not been advanced
        // or if there is small unused capacity if we reuse the buffer.
        let has_advanced = iterator.buf.as_ptr() as *const _ != iterator.ptr;
        if !has_advanced || iterator.len() >= iterator.cap / 2 {
            unsafe {
                let it = ManuallyDrop::new(iterator);
                // If it has been advanced, we reuse the memory by moving
                // the data to the front.
                if has_advanced {
                    ptr::copy(it.ptr, it.buf.as_ptr(), it.len());
                }
                return Vec::from_raw_parts(it.buf.as_ptr(), it.len(), it.cap);
            }
        }

        // We use a conservative method to grow a new Vec with the generic
        // from_iter if there is a large unused capacity after the
        // optimization above. This limitation is not strictly necessary as
        // Vec's allocation is intentionally unspecified.
        let mut vec = Vec::new();
        // must delegate to spec_extend() since extend() itself delegates to spec_from for empty
        // Vecs
        vec.spec_extend(iterator);
        vec
    }

While writing the documentation, iterator.len() >= iterator.cap / 2 does seem to look weird to me, looks kinda magical and I wonder if that works with both large and small capacity. Is there any reason why we are not comparing it with size hint too?

@the8472 Any suggestion to make it better? I tried my best already.

    fn from_iter(iterator: IntoIter<T>) -> Self {
        // It is common to pass a vector to a function which immediately
        // re-collects as a vector. We can short circuit this behavior if
        // the IntoIter has not been advanced.
        let has_advanced = iterator.buf.as_ptr() as *const _ != iterator.ptr;
        if !has_advanced || iterator.len() >= iterator.cap / 2 {
            unsafe {
                let it = ManuallyDrop::new(iterator);
                // If it has been advanced, we reuse the memory by moving
                // the data to the front.
                if has_advanced {
                    ptr::copy(it.ptr, it.buf.as_ptr(), it.len());
                }
                return Vec::from_raw_parts(it.buf.as_ptr(), it.len(), it.cap);
            }
        }

        // A conservative choice to grow a new Vec with the generic from_iter
        // if there is a large unused capacity after the optimization above.
        // This limitation is not strictly necessary as Vec's allocation is
        // intentionally unspecified.
        let mut vec = Vec::new();
        // must delegate to spec_extend() since extend() itself delegates to spec_from for empty
        // Vecs
        vec.spec_extend(iterator);
        vec
    }

What do you think?