text:
macos: linking errors with split-debuginfo and switching toolchains

I am getting linking errors when switching between different toolchains on macos using split-debuginfo.
Reproduction
Create a new binary cargo project foo and add the following to Cargo.toml:
[profile.dev]
split-debuginfo = "unpacked"

Run in this order:

cargo +stable build
cargo +nightly build
cargo +stable build

Where stable is 1.51 and nightly is 1.53.  This will also happen with the inverse order (nighty/stable/nightly) or using beta 1.52.  The last steps results in the error:

Compiling foo v0.1.0 (/Users/eric/Temp/foo)
error: linking with cc failed: exit code: 1
|
= note: "cc" "-m64" "-arch" "x86_64" "-L" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/eric/Temp/foo/target/debug/deps/foo.133wdq044u90e7l6.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.14w9ua3dropu18oz.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.1hu7398ixp3j8hr7.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.2w3g7gdejx58fp4w.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.400r4iosyqzwmm34.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.4ew8o84rdo0pqe67.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.4pil1rvk4hlgrvxn.rcgu.o" "/Users/eric/Temp/foo/target/debug/deps/foo.59wg0cocv7vr0nej.rcgu.o" "-o" "/Users/eric/Temp/foo/target/debug/deps/foo" "/Users/eric/Temp/foo/target/debug/deps/foo.2f3bbrl2dzwum699.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/eric/Temp/foo/target/debug/deps" "-L" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-349f286494d73b18.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-0c9fcc24a503d489.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libobject-70419d92d1ba4b1d.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libaddr2line-65e88774cb68bd46.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libgimli-3849b3781a19a398.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_demangle-0dbb03fa66ca6d84.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libhashbrown-65edff8661311c85.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_alloc-599e707cd7ee7216.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-40cb05f6c516791a.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcfg_if-7a0a923a4d37a048.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-7e047938e88325ef.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-02542d835be27c0f.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_core-63712b18a1365082.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-1196a2a060497e71.rlib" "/Users/eric/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-10db70d883838cbc.rlib" "-lSystem" "-lresolv" "-lc" "-lm"
= note: Undefined symbols for architecture x86_64:
"std::rt::lang_start::h101df5f7d98767d0", referenced from:
_main in foo.4pil1rvk4hlgrvxn.rcgu.o
"core::fmt::Arguments::new_v1::h8105d8d713b7c82d", referenced from:
foo::main::hb50b1ea1f0945408 in foo.4pil1rvk4hlgrvxn.rcgu.o
"std::io::stdio::_print::h0aab2456a28edb0d", referenced from:
foo::main::hb50b1ea1f0945408 in foo.4pil1rvk4hlgrvxn.rcgu.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I expected the 3rd build to rebuild from scratch and replace the output binary with success.
One curious thing I noticed is that the different toolchains produce mostly different .o filenames, but two of the filenames are the same.  foo.4pil1rvk4hlgrvxn.o is one of those files.  I am a bit confused, as I would assume rustc would have completely replaced any overlapping files, so I'm uncertain how conflicting filenames could be a problem here.  I could imagine other scenarios involving rlibs where this would be a problem, but not with just a single binary.
Out of curiosity, I collected the unmangled names and here is the comparison:

nightly
stable

foo.core.alx3lauo-in-foo.7k7dwitq-fmt.rcgu.o
foo.core.3y4jtb65-in-foo.7k7dwitq-fmt.rcgu.o

foo.core.alx3lauo-in-foo.7k7dwitq-hint.volatile.rcgu.o
foo.core.3y4jtb65-in-foo.7k7dwitq-hint.volatile.rcgu.o

foo.foo.7k7dwitq.rcgu.o
foo.foo.7k7dwitq.rcgu.o

foo.foo.7k7dwitq-fallback.cgu.rcgu.o
foo.foo.7k7dwitq-fallback.cgu.rcgu.o

foo.std.83sbzbw6-in-foo.7k7dwitq-process.rcgu.o
foo.std.76rm7o7m-in-foo.7k7dwitq-process.rcgu.o

foo.std.83sbzbw6-in-foo.7k7dwitq-rt.volatile.rcgu.o
foo.std.76rm7o7m-in-foo.7k7dwitq-rt.volatile.rcgu.o

foo.std.83sbzbw6-in-foo.7k7dwitq-sys-unix-process-process_common.rcgu.o
foo.std.76rm7o7m-in-foo.7k7dwitq-sys-unix-process-process_common.rcgu.o

foo.std.83sbzbw6-in-foo.7k7dwitq-sys_common-backtrace.volatile.rcgu.o
foo.std.76rm7o7m-in-foo.7k7dwitq-sys_common-backtrace.volatile.rcgu.o

foo.foo.7k7dwitq-crate.allocator.rcgu.o
foo.foo.7k7dwitq-crate.allocator.rcgu.o

I think the underlying problem is that the -C metadata flag is the same across toolchains for binaries on macos.  This causes the crate disambiguator to be the same, causing the cgu hash to be the same.  This is exposed here.  I think the solution will be to include the rustc version in the target_short_hash, though I don't remember if that needs to be stable across versions.
There are a few other scenarios where Cargo reuses metadata hashes (described here) that will need to be investigated if they also suffer from this issue.
I'm still a bit confused why rustc doesn't just overwrite the files.

This looks like an odd interaction with incremental, if you set CARGO_INCREMENTAL=0 it works ok (or if you blow away target/debug/incremental between compiles). I think rustc is using the same incremental directory and with the same format on stable/nightly so it's copying out the stale object file?
I agree though that the fix here is to probably ensure that -Cmetadata is different on nightly/stable where it currently isn't.

I think rustc is using the same incremental directory and with the same format on stable/nightly so it's copying out the stale object file?

This has me worried that there might be a bigger underlying problem, but I don't see how it is possible.  My understanding of the incremental cache is that it validates the rust version and if it doesn't match, it deletes the incremental cache. Any ideas how stale cache data could infect the new build?

Oh I was just assuming that was the case since I think object files are stored separately than other metadata in the cache and so it may bypass other forms of version-checking logic? (I'm not sure if a version check mismatch invalidates just one piece of data or the entire incremental directory that was specified)

Oh interesting! I suppose this is a case where rustc is not removing a file before opening it for writing?

I'm confused why those files would be hardlinked. I don't think we should be sharing object files between different versions of Rust; a build with cargo +nightly build should make sure all objects were built with that nightly toolchain.

To clarify, the sequence is:

first build with rustc stable:

rustc stable writes .o files in the output directory (target/debug/deps)
the .o files are hard-linked into the stable incremental directory copy_cgu_workproduct_to_incr_comp_cache_dir

second build with rustc nightly:

rustc nightly writes .o files in the output directory (target/debug/deps). This does not unlink the file, but instead opens the existing file and truncates it LLVMRustWriteOutputFile. Since this file is hard-linked into the stable incremental directory, this means it is writing (corrupting) the stable incremental cache.
the .o files are hard-linked into the nightly incremental directory

third build with rustc stable:

Loading and reusing the data from the incremental cache, but the cache contains the wrong data, so the linking fails.

I haven't finished my investigation on reworking the hash behavior. I think using the correct -C metadata flags should solve the problem. Another option is to change rustc to unlink the .o file before writing to it instead of truncating, but I'm not sure if that is necessary.

authors: alexcrichton ehuss joshtriplett


text:
Improve the profiling output of Cargo

Don't use {:?} in profiling output, it's too noisy
Allow an integer to be specified with CARGO_PROFILE indicating how many
levels deep should be printed.

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

@bors r+

 @bors r=brson ffbb8cc

:hourglass: Testing commit ffbb8cc with merge e4f0662...

:sunny: Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-32, cargo-win-64

source: gharchive/pull-request

authors: alexcrichton bors brson rust-highfive

repo: rust-lang/cargo

license_type: permissive

license_source: github-api


text:
Add some help with updating the registry in offline mode.

This includes the following:

Move offline tests to a dedicated file.

If an index has never been downloaded, and -Z offline is used, provide a suggestion to run without -Z offline.

If an index needs to be updated, and the network appears to be down, suggest running with -Z offline.

The offline_resolve_optional_fail test is added to show that resolver errors are still possible (though hopefully rare!).

This is an attempt to improve some error message, but I'm on the fence if it actually does that, so I figured I'd post this for comments.
I think repo.is_empty() should be a reliable way to determine if the repository has never been fetched, but I'm not certain.
I'm not sure if the offline && is_empty() check might give a false positive for the error. I can't think of any, though.
The maybe_spurious check may have false positives.
I'm not sure if the wording is clear.

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

OK, I reverted the spurious error, and tweaked the text of the other one.

@bors: r+

:pushpin: Commit c6fad3af85b0cf284c9c19b0acbe91fcfa004529 has been approved by alexcrichton

:hourglass: Testing commit c6fad3af85b0cf284c9c19b0acbe91fcfa004529 with merge 2de6c3ef2b813d0f57e987c5827394688f60d9cd...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 2de6c3ef2b813d0f57e987c5827394688f60d9cd to master...

authors: alexcrichton bors ehuss rust-highfive


text:
moxie-dom: retry ancient build from '19

Crate name
moxie-dom
Build failure link
https://docs.rs/crate/moxie-dom/0.2.2/builds
Additional details
this is sufficiently old, surely docs.rs supports the wasm32-unknown-unknown target by now: will a simple rerun get me docs?

Queued a new build, we'll see if it works in a couple minutes.

Looks like it's hitting compile errors in a dependency: https://docs.rs/crate/moxie-dom/0.2.2/builds/913387

Ah well, thanks @Nemo157 !

source: gharchive/issue

license: MIT


text:
ci: add support for loongarch64-unknown-linux-musl

Description

Fix libc-tests for loongarch64-unknown-linux-musl.
Add support for loongarch64-unknown-linux-musl target in CI.

Sources
None.
Checklist

[x] Relevant tests in libc-test/semver have been updated
[x] No placeholder or unstable values like *LAST or *MAX are
included (see #3131)
[x] Tested locally (cd libc-test && cargo test --target mytarget);
especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

repo: rust-lang/libc


text:
Poor performance in some cases compared to oniguruma

I'm looking at replacing oniguruma with regex in some situations for the Ruby that I'm building.
I am benchmarking the following three Regexps over this several megabyte text corpus:
bench('Email', '[\w\.+-]+@[\w\.-]+\.[\w\.-]+')
bench('URI', 'https?://(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)')
bench('IP', '\b(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\b')

For Email, regex is 10x faster than oniguruma. For URI, regex is 2x slower than oniguruma. For IP, regex is 20x slower than oniguruma.
regex performance
Email: 92 matches
..................................................

    compile: 85.52ms elapsed in 50 iterations (avg. 1.71ms / iteration)
    scan: 1569.22ms elapsed in 50 iterations (avg. 31.38ms / iteration)
    scan with block: 1025.49ms elapsed in 50 iterations (avg. 20.5ms / iteration)

URI: 5388 matches
..................................................

    compile: 71.84ms elapsed in 50 iterations (avg. 1.43ms / iteration)
    scan: 2336.46ms elapsed in 50 iterations (avg. 46.72ms / iteration)
    scan with block: 2045.79ms elapsed in 50 iterations (avg. 40.91ms / iteration)

IP: 6 matches
..................................................

    compile: 10.79ms elapsed in 50 iterations (avg. 0.21ms / iteration)
    scan: 25693.73ms elapsed in 50 iterations (avg. 513.87ms / iteration)
    scan with block: 25642.21ms elapsed in 50 iterations (avg. 512.84ms / iteration)

oniguruma performance (via rust-onig)
Email: 92 matches
..................................................

    compile: 5.89ms elapsed in 50 iterations (avg. 0.11ms / iteration)
    scan: 16335.45ms elapsed in 50 iterations (avg. 326.7ms / iteration)
    scan with block: 16228.96ms elapsed in 50 iterations (avg. 324.57ms / iteration)

URI: 5388 matches
..................................................

    compile: 1.68ms elapsed in 50 iterations (avg. 0.03ms / iteration)
    scan: 1366.95ms elapsed in 50 iterations (avg. 27.33ms / iteration)
    scan with block: 1349.82ms elapsed in 50 iterations (avg. 26.99ms / iteration)

IP: 6 matches
..................................................

    compile: 3.79ms elapsed in 50 iterations (avg. 0.07000000000000001ms / iteration)
    scan: 1465.14ms elapsed in 50 iterations (avg. 29.3ms / iteration)
    scan with block: 1431.35ms elapsed in 50 iterations (avg. 28.62ms / iteration)

If you're interested in doing so, you can invoke this benchmark in Artichoke with:
cargo run --release --bin string_scan_bench -- artichoke-frontend/ruby/benches/string_scan.rb

The benchmark on master (with oniguruma) is different than the benchmark on this branch because I've tweaked the Regexps to remove lookahead patterns.

Compile times are also significantly slower but that seems to be a known property: https://github.com/rust-lang/regex/pull/452

Hiya! Thanks for doing an analysis and reporting this issue. I appreciate it. I have two high level thoughts off the bat:

If Artichoke is truly meant to be a drop-in replacement for Ruby, you'll definitely want to be careful with when you use the regex crate. It could have subtly different matches in some cases.
I don't know where to look to see how you're building these regexes. My first thought is that you have Unicode enabled with the regex crate (which is on by default), but do not have Unicode enabled in Oniguruma? I confess I am less familiar with Oniguruma, so I don't know what its defaults all, but for example, PCRE does not have Unicode support enabled by default. I looked at the onig crate docs, but found zero mentions of Unicode anywhere. Looking at the Oniguruma docs itself, there is clearly a Unicode and not-Unicode mode for classes like \w, although it does not say whether its word boundaries are Unicode aware. There's otherwise zero mention of Unicode in the API docs. Okay, so I found this, which seems to imply that the interpretation of \w is based on the selected encoding? (Which seems weird to me.) Either way, this needs to be figured out in order to do an accurate comparison.

With all that said, I can likely explain why the URI and IP benchmarks are so much slower. My guess is because you are using a Unicode word boundary on text that is not entirely ASCII (both of those conditions must be true). Specifically, this is one of the few explicit cases that the faster DFA just cannot handle. So when it has a Unicode word boundary and it sees a non-ASCII byte, the DFA quits and falls over to a much slower engine. This is explained in more detail in the PERFORMANCE.md guide.
So, if you actually need Unicode support here, then you ought to make sure your benchmarking with equivalent options. If the regex crate still turns up slower, then that's a known thing that is unlikely to be fixed any time soon. Otherwise, if you can use the ASCII-only interpretation of everything, then just disable Unicode mode (either with RegexBuilder or by adding (?-u) to the beginning of the regex pattern), and things should hopefully speed up.

Compile times are also significantly slower but that seems to be a known property: #452

It is known, yes, but #452 is the wrong thing to look at. The PR talks about parse time, which is typically an overall very small portion of total compilation time of a regex. Your regexes aren't exactly small, and you're using some fairly large Unicode classes in your Email benchmark, which is likely why it is the slowest to compile.

@BurntSushi thank you for the detailed response. I have an easy way of answering how \b behaves in Oniguruma: I can use MRI Ruby to match some Regexps.
MRI:
[2.6.0] > "\u3031".encoding
=> #<Encoding:UTF-8>
[2.6.0] > "\u3031"
=> "〱"
[2.6.0] > "\u3031".encoding
=> #<Encoding:UTF-8>
[2.6.0] > /\b/ =~ "\u3031"
=> 0
[2.6.0] > " α".encoding
=> #<Encoding:UTF-8>
[2.6.0] > /\b/ =~ " α"
=> 1

I need to support non-ASCII word boundaries.
Thinking about how I can work around this pathological case:

I already was planning on bundling oniguruma because I need to support backreferences and lookahead.
Use regex crate as a fast path if it can successfully compile the regex and the pathological DFA conditions are not present. Otherwise fallback to oniguruma.
Presence of non-ascii bytes is easy to detect with Rust String APIs.

Does Regex expose whether the compiled regex contains \b character classes or will I need to separately parse and walk the HIR? Would you be open to exposing this API given the known limitations of the DFA?

No, there's no way to tell whether the regex contains a Unicode \b other than by parsing it. I don't think I want to expose this as an API in the regex crate itself. It's really an implementation detail.
It sounds like there isn't anything to be done here on my end. Some day, I'd like to try and fix the Unicode \b issue, but it's hard.

Thank you @BurntSushi for helping me to find a path forward.

authors: BurntSushi lopopolo

repo: rust-lang/regex

license_source: bigquery


text:
fix memory usage regression for RegexSet with capture groups

Basically, if one used a RegexSet with capturing groups in it, then as of regex 1.9, it would unnecessarily allocate space for those capture groups in the PikeVM. A Thompson NFA (and specifically the PikeVM) does not scale well with respect to the both the size of the NFA and the number of capture groups, and so this resulted in exorbitant memory usage even for medium sized regex sets. This is a bit of weird case, since it requires using capture groups in a regex set even though it's impossible to extract any capture information from the RegexSet API. (The regex-automata crate does expose APIs to do this for multi-regexes, hence the new memory usage requirements.) So normally this wouldn't apply, but it turns out that globset produces regex sets with capture groups in them. However, even after fixing that, memory usage is still exorbitant because of the capture states inserted to track an overall match. Regex sets don't expose a way to get match offsets either, and so even those addition states are superfluous.
This PR introduces a path in regex-automata to get back to the original memory usage by making the PikeVM and bounded backtrackers work with NFAs that have no capture states at all. Previously, constructing such engines would result in an error. Now those constructions will succeed, but asking for the match offsets with result in "no match" being reported. (Since without the capture states in the NFA, the PikeVM can't track the match offsets.)
Fixes #1059

Note that this PR changes globset to use non-capture groups in all cases when translating a glob to a regex. While that ameliorates the issue reported in #1059, it does not fully fix it. Without this patch here, the PikeVM would still insert capture states for implicit capture groups, which are only truly needed to track match offsets. Since RegexSet cannot report match offsets, these are superfluous.


text:
Extern types v2

Define types external to Rust and introduce syntax to declare them.
This additionally introduces the MetaSized trait to allow these types to be interacted with in a generic context.
This supersedes #1861, and is related to the open RFCs #2984 and #3319.
Rendered

Should MetaSized be a supertrait of Sized?

Yes, I think so, unless there are plans to add types that are Sized but not MetaSized, which makes no sense IMO.
Personally, I think it would be better to leave the meaning of ?Sized unchanged. MetaSized could be a trait that is automatically implied for trait bounds, so these are semantically identical:
fn foo<T>();
fn foo<T: Sized + MetaSized>();

as are those:
fn foo<T: ?Sized>();
fn foo<T: ?Sized + MetaSized>();

In other words, MetaSized would be opt-out rather than opt-in, like Sized is today. And if MetaSized is a super-trait of Sized, then you can opt-out of both traits with ?MetaSized, which is convenient.
Note that this is not a breaking change and requires no edition migration.

then you can opt-out of both traits with ?MetaSized

FWIW, lang has historically said "no more ?Trait bounds" like this.  That's why there's no ?Move, no ?Unpin, no ?AlignSized , etc.
So I like the edition switch approach here: the conceptual meaning of ?Sized is still essentially the same, and code that just wants to deal in references can continue to use T: ?Sized, with only code that needs to look at the dynamic size of something needing to add the extra bound.  (You can follow old docs that say ?Sized, and if you do something that needs the runtime size it'll be an obvious error message saying to add the + MetaSized.)

Since the general consensus on the syntax is... very mixed, it might be worth focusing on MetaSized and it's semantics first, and maybe delegating the exact way to define extern types to another RFC?
Having a stable MetaSized would allow libraries to determine a strategy of handling extern types while we figure out the syntax, and the semantics seem like the largest barrier to getting that right now.
I just don't want to see more progress on refining Sized semantics for DSTs get canned because of syntax bikeshedding.

What is the reasoning that optional traits aren't allowed in supertraits? I feel like a builtin trait JustSizedEnough: ?Sized + MetaSized {}  may be useful to reduce the clunkiness of ?Sized + MetaSized. This combined bound is expected to be used more often than just ?Sized outside of FFI, right?
Also, is this understanding in this table correct? It might be good to include some kind of table or diagram in the RFC, I've found it kind of hard to wrap my head around just the text.

bound
implied by the bound
note

Sized
MetaSized
implemented for everything by default

MetaSized
nothing (?Sized)
unsized types like str or [T] (?Sized  + MetaSized is needed to allow these types)

!Sized
!MetaSized
something that is !Sized can never be MetaSized

This combined bound is expected to be used more often than just ?Sized outside of FFI, right?

An owning pointer use will generally want ?Sized + MetaSized, and a non-owning pointer use will generally want ?Sized + ?MetaSized. The size of a non-owned object is only really needed if you're going to replace it, which happens fairly rarely in generic code, and when it does, usually you are also manipulating values by-ownership.
Interestingly, with implied bounds, fn<T: ?Sized>(Box<T>) would be able to still imply T: MetaSized. I don't know if the fundamentalness of MetaSized are enough to overwhelm the known pitfalls with implied bounds, though.

What is the reasoning that optional traits aren't allowed in supertraits?

Because ?Sized isn't adding a bound, it's opting out of one. When you write fn<T>, there's an invisible implied bound of T: Sized, unless you say that T: ?Sized.
Traits don't have this default implied bound of Sized, so ?Sized doesn't mean anything as a supertrait bound. Writing fn<T: JustSizedEnough> is the same as writing fn<T: Sized + JustSizedEnough>, and writing fn<T: ?Sized + Sized> is the same as writing fn<T: Sized>.
I didn't actually review the RFC for this, but if it doesn't yet, it should say that traits have a default MetaSized bound in editionBefore and no longer do in editionAfter (matching the behavior of ?Sized). It also needs to specify how this interacts with dyn; is Self: MetaSized dyn-safe, is Self: ?MetaSized, and when does dyn Trait: MetaSized hold?

!Sized

!Sized isn't a bound. !Sized is a colloquial way of referring to types where T: Sized doesn't hold, so colloquially we would say that str is !Sized + MetaSized. T: ?Sized thus says to permit both Sized and !Sized types.

@tgross35 I agree with what CAD97's said, I'm confused by your table and don't understand what you're trying to convey. Sized implies MetaSized (in fact I'm now convinced that it should be a supertrait of Sized) so all things that are Sized are MetaSized, but some things are not Sized but are MetaSized (eg trait objects), and finally extern types are neither.
@CAD97

I don't know if the fundamentalness of MetaSized are enough to overwhelm the known pitfalls with implied bounds, though.

I'm beginning to worry that this RFC will require implied bounds to be acceptable, can you link to the known pitfalls with implied bounds?

I didn't actually review the RFC for this, but if it doesn't yet, it should say that traits have a default MetaSized bound in editionBefore and no longer do in editionAfter (matching the behavior of ?Sized). It also needs to specify how this interacts with dyn; is Self: MetaSized dyn-safe, is Self: ?MetaSized, and when does dyn Trait: MetaSized hold?

I hadn't considered this actually, I'll update the RFC soon. dyn Trait is always MetaSized (in fact the vtable directly holds the size and alignment so the implementation is nice and obvious) so I think there isn't much interaction between this and object-safety.

For anyone following along there was a lang team design meeting about this yesterday, the minutes are available here: Extern types V2 - HackMD. There's also some Zulip discussion here: #t-lang > Design meeting 2023-08-09 - rust-lang - Zulip
That meeting came out with some suggestions for investigations that would help move this RFC along, the current set of things I think need doing are:

[ ] Clarify dereferencing is allowed but place-to-value coercion is not.
[ ] Remove uses of "opaque types" to reduce confusion with impl Trait
[ ] Make MetaSized a supertrait of Sized
[ ] Clarify implicit MetaSized bound on traits that drops on edition change.
[ ] Investigate how many ?Sized bounds would now need + MetaSized
[ ] Investigate whether the MetaSized bound can be removed on Box (and similar) so that it no-one needs to type it when just mentioning boxed things (the drop impl currently needs it to deallocate).

Sized is an auto trait, but auto traits can't have trait bounds and MetaSized can't be an auto trait due to having methods.

@tgross35 I agree with what CAD97's said, I'm confused by your table and don't understand what you're trying to convey. Sized implies MetaSized (in fact I'm now convinced that it should be a supertrait of Sized) so all things that are Sized are MetaSized, but some things are not Sized but are MetaSized (eg trait objects), and finally extern types are neither.

I didn't put it together very well, but what I was going for was:

Anything with a Sized bound (doesn't specify ?Sized) will always be MetaSized - this is the default case
Something that is MetaSized may or may not be Sized, which is why you must specify ?Sized + MetaSized
Something that is strictly not Sized can never be MetaSized

Based on your comment it sounds like item 1 is implied (by MetaSized being a supertrait of Sized), item 2 is true, and item 3 is just contradictory to item 2 🙃.

What is the reasoning that optional traits aren't allowed in supertraits?
Because ?Sized isn't adding a bound, it's opting out of one. When you write fn, there's an invisible implied bound of T: Sized, unless you say that T: ?Sized.

Traits don't have this default implied bound of Sized, so ?Sized doesn't mean anything as a supertrait bound. Writing fn<T: JustSizedEnough> is the same as writing fn<T: Sized + JustSizedEnough>, and writing fn<T: ?Sized + Sized> is the same as writing fn<T: Sized>.

Thanks for the explanation. I know the discussion of trait aliases came up before, it just seems unfortunate that two traits ?Sized + MetaSized bound is now needed in many places where ?Sized works. But, I suppose that is what this step is meant to determine

[ ]  Investigate how many ?Sized bounds would now need + MetaSized

(This is mostly a brain dump so I don't forget it)
boats' post Changing the rules of Rust has made me realise that my plan of relaxing the meaning of ?Sized has backwards compatibility hazards that may prove problematic. Specifically any traits containing associated types can't obviously have the bounds on those associated types be weakened. This would be a massive problem for, e.g., the Deref trait, however I think we might be able to work around it by treating all pre-2024 code as implicitly having bounds like Deref::Target: MetaSized everywhere that they place a bound using a trait with an associated type.
Worse however is traits that contain functions that are generic over their argument because implementations of those traits could rely on T: ?Sized being MetaSized. However, with this doozy of a command:
jq '. as $root | .index[] | select(.crate_id == 0) | select(.inner | has("trait")) | (.inner.trait.items[] |= $root.index[.]) | select(.inner.trait.items[].inner.function.generics | .. | .modifier? == "maybe") | .name'

run over the standard library rustdoc json output, I believe the only stdlib trait this affects is RangeBounds because of its contains method. This is probably fine, but may present an issue still because it could force breaking changes to a bunch of ecosystem traits, for example serde's `Serializer` trait`, if they wanted to support these types.

I got curious and ended up writing a partial implementation of ?MetaSized[^impl] for the current edition (i.e. ?Sized still implies MetaSized, but ignoring anything beyond the trait itself). My goal was to change as few library unbounds to ?MetaSized as are required[^unbounds]. I think my major takeaways got brought up thanks to boats' post, but as a short list:
[^impl]: I build the +stage1 compiler with (incomplete) ?MetaSized support, but then error during x check --stage 1 trying to derive Copy for ParamEnv, as for some reason it's determined that the std::marker::Copy impl for CopyTaggedPtr<&'tcx list::List<Clause<'tcx>>, ParamTag, true> requires that list::OpaqueListContents: std::marker::MetaSized (an extern type). I think it's actually the requirement P = &List<_>, P: Pointer, Pointer: Deref, since I still have Deref::Target: ?Sized; the odd error timing (the bound is structural on CopyTaggedPtr) is likely due to fast-accept paths for &_: Deref.
[^unbounds]: I only relaxed ?Sized to ?MetaSized for *const T, *mut T, &T, &mut T, NonNull<T>, PtrRepr<T>, PhantomData<T>, Unsize<U> (both U and Self), Pointee (Self), and the feature(ptr_metadata) fn.

Current edition code should be able to write ?MetaSized. But I do generally agree that next edition code should have ?Sized unbound MetaSized as well and write ?Sized + MetaSized for current edition ?Sized.
A decent amount of code assumes only one ?Trait unbound may be present.
traits need a default Self: MetaSized bound/supertrait.[^supertrait] We elaborate supertrait bounds, so relaxing this implied bound on a trait should be semver-incompatible.{^supertrait-break]
MetaSized is an object safe supertrait, so now most object safe traits fire warn(multiple_supertrait_upcastable) since the MetaSized supertrait is considered upcastable.[^upcast]
When you write a generic list for<T: Deref>, this needs to be elaborated to essentially for<T: Deref<Target=$0>, $0: ?Sized + MetaSized>, where the ?Sized unbound is determined by ?Sized's presence on the associated item definition, but the MetaSized (un)bound is determined by ?MetaSized's presence in this bounds context, and this elaboration needs to be recursive.[^assoc]

[^supertrait]: I sort of do this -- adding a predicate alongside the Self: Trait predicate -- but with a huge hack where Unsize and Pointee are specifically opted out instead of looking for a ?MetaSized bound.
[^supertrait]: ...except that my implementation doesn't actually make the MetaSized bound visible in such a way that it gets elaborated currently, so it's accidentally semver-compatible to remove the non-elaborated supertrait bound.
[^upcast]: I just hacked around this problem by ignoring MetaSized in the lint. The better solution is to exclude MetaSized from dyn upcast eligibility... which actually the implied bound currently isn't permitted as a trait upcast by my impl, though it might still be put into the vtable; I didn't check.
[^assoc]: I was unable to figure out a way to do this bound elaboration yet, so my incomplete impl currently just doesn't. This is necessary because Deref::Target needs to be relaxed to ?MetaSized for basically anything to work.

When you write a generic list for<T: Deref>, this needs to be elaborated to essentially for<T: Deref<Target=$0>, $0: ?Sized + MetaSized>, where the ?Sized unbound is determined by ?Sized's presence on the associated item definition, but the MetaSized (un)bound is determined by ?MetaSized's presence in this bounds context, and this elaboration needs to be recursive.5

I cannot parse your syntax here and have no idea what you are talking about, could you explain in more detail? (Like, there's literally no sentence in what I quoted that I can make sense of.)

It's easiest to explain by example:
// Assuming some trait associated type, e.g.
trait Deref {
    type Target: ?MetaSized;
    // ...
}

// when declaring the function
fn f<P: Deref>()
// this needs to be treated as having
where
    <P as Deref>::Target: MetaSized,
{
    // because the code might have previously relied on that bound, e.g.
    _ = size_of_val::<P::Target>;
}

// This application of implicit bound needs to be applied recursively;
// consider e.g.
trait Strategy {
    type Pointer: Deref
    where
        <Self::Pointer as Deref>::Target: ?MetaSized,
        // NB: bound would be implied here without unbound
    ;
}

// Then with a function defined as
fn g<S: Strategy>() {
    // we need both S::Pointer: MetaSized
    _ = size_of_val::<S::Pointer>;
    // and S::Pointer::Target: MetaSized
    _ = size_of_val::<<S::Pointer as Deref>::Target>;
}

It is technically an option to say that relaxing an associated type to unbound ?MetaSized is a major breaking change, but this is essentially untenable because Deref is critical to basic functionality which should continue to work for extern types. If we need to apply this implicit projected bound at preprojection bound declaration for existing traits anyway, it makes more sense to apply it to all trait projections than only some.[^mid]
[^mid]: There's an awkward middle ground where existing traits can opt into getting associated type MetaSized obligations elaborated, but new traits can have their associated types not get it. This enables traits to use impl detail associated types which are ?MetaSized without downstream current edition needing to unbound them. I don't even know if it's possible to make a type projection usable in your crate but not downstream without resorting to unreachable pub tricks, which would still get the implicit bound applied.
This actually makes me realize one more edge case to consider: trait DerefExt: Deref needs to have an implied bound of <Self as Deref>::Target: MetaSized as well, as default method bodies are currently able to (in effect) rely on the presence of that bound.
When to not apply the implicit bound is a bit more involved. If a generic binder context (params and where clause) introduces a trait obligation T: Deref (even for nongeneric T!), then an implicit obligation on the projection of <T as Deref>::Target: MetaSized needs to be introduced to the binder unless that same binder also contains a <T as Deref>::Target: ?MetaSized unbound[^unb] or we already have an equality constraint on the projection (typically written in source as T: Deref<Target = U>) in which case the implicit bounds on U of course apply instead. The recursive property is that <T as Deref>::Target may itself contain some positive obligations (Deref doesn't, but Strategy above does), any trait bound obligations introduced for the projected type also need this implicit bound to be added in order to ensure current edition code is never exposed to ?MetaSized generics/projections without writing the ?MetaSized unbound themselves.
[^unb]: Note that unbounds in this position (on a type other than a generic parameter introduced by that binder) are currently always a semantic error.
The extent of needing to apply MetaSized implicit bounds everywhere does make me wonder if it could be simpler to "just" "give up" and have the current edition code entirely unable to use ?MetaSized unbounds, with every reachable placeholder/generic type obligated to be MetaSized. It would be a strong cutoff between editions (and maybe even justify a distinctly settable dialect axis), but generically consuming ?MetaSized types can be expected to be rare. But I don't think applying a universal implicit obligation is really made significantly easier by not doing so in a way capable to being unbound. But I could see not allowing projection unbounds in the current edition, at least. Perhaps even supertrait unbounds[^sup]?
[^sup]: Supertrait MetaSized is actually one case where I'm wondering if it could be desirable to keep it as an implicit bound with an unbound even in the next edition. The reason is that the implicit bound is enabled to behave differently from an explicit bound; namely, be exempt from dyn upcasting (but allow it for an explicit bound for consistency) and not be elaborated (such that adding the unbound is nonbreaking), which is potentially desirable. On the other hand, traits do fine without an implicit Sized and adding Sized when necessary, so there's reasonably little reason to have a conservative MetaSized bound either.
Pessimistic takeaway: extern type support in the current edition is going to feel awkward no matter what we do, in order to forbid ?MetaSized types from "leaking". The best we can do is to make it acceptably predictable and at least somewhat usable, then clean it up to our regular standards for the next edition.
Making ?Sized the only unbound again does seem to be the better solution for the future, but with one potential exception I just thought of and want to point out: dyn Trait. Unowned &dyn Trait can be ?MetaSized just fine, but it would seem unfortunate to require that most owned trait objects specify Box<dyn Trait + MetaSized> instead.

This actually makes me realize one more edge case to consider: trait DerefExt: Deref needs to have an implied bound of <Self as Deref>::Target: MetaSized as well, as default method bodies are currently able to (in effect) rely on the presence of that bound.

You could gate the default method bodies behind the implied bound without gating the trait itself, as MetaSized would presumably be specialization-safe (no lifetime-dependent impls).

Cool

@GoldsteinE unless I misunderstand what MetaSized/MetaAligned are, isn't Foo not just MetaAligned, but Aligned (i.e. the alignment is statically known even without metadata, similarly to slices).
Would also be nice to be able to specify "the same alignment as T", but that's besides the point.

@WaffleLapkin Sure, it’s also Aligned. MetaAligned still seems to me like a more natural restriction for a tail field, although I’m not sure MetaAligned + !Aligned types are even achievable without fully custom DSTs.

Would also be nice to be able to specify "the same alignment as T", but that's besides the point.

I think that with generic_const_exprs it would be just Aligned<ALIGN = align_of::<T>()>.

@nikomatsakis has written https://smallcultfollowing.com/babysteps/blog/2024/04/23/dynsized-unsized/ which suggests an alternative to relaxing ?Sized by using positive bounds (e.g. : MetaSized) that inherently relax the implied Sized bound. I'm sure I saw this suggestion before too but also have no idea where I saw it.
This suggestions should definitely go into the alternatives section at the very least, the way I see it the pros are:

It doesn't require an edition boundary to make the change.
It gets rid of the somewhat confusing ?Sized notation

The cons are:

The implied relaxation of Sized could be surprising (especially if it works in supertraits), T: Unsized isn't really a bound at all, as it doesn't let the function assume anything about T making these traits especially weird.
trait definitions currently assume Self is ?Sized + MetaSized (kinda? they allow functions that require Sized too which is odd), if this proposal means that in order to use a trait with an extern type it would have to be declared trait Foo: Unsized, it would be annoying to use them as it's likely crates would forget to do that.

trait definitions currently assume Self is ?Sized + MetaSized (kinda? they allow functions that require Sized too which is odd), if this proposal means that in order to use a trait with an extern type it would have to be declared trait Foo: Unsized, it would be annoying to use them as it's likely crates would forget to do that.

Hmm, I overlooked that, I think we would want to use an edition for this.

authors: Aloso CAD97 GoldsteinE Jules-Bertholet RalfJung Skepfyr WaffleLapkin bjorn3 clarfonthey nikomatsakis scottmcm snmps2 tgross35

repo: rust-lang/rfcs


text:
[RFC] Target Modifiers

We introduce the concept of "target modifier". A target modifier is a flag where it may be unsound if you link together two compilation units that disagree on the flag.
We fail the build if rustc can see two Rust compilation units that do not agree on the exact set of target modifier flags.
There are already several existing flags that could fall into this category. There are also hypothetical new flags that do.
The error can be silenced using the -Cunsafe-allow-abi-mismatch escape hatch.
Not having a stable way to build stdlib crates does not block stabilization of target modifiers.
As a future extension we may be able to relax the rules to allow some specific kinds of mismatches.
This RFC does not stabilize any target modifiers. That should happen in follow-up MCPs/FCPs/RFCs/etc.

Rendered

It turns out you need to use the correct bot to do that.
@rfcbot fcp merge

I'd say that we should ship this feature without a stable way to disable it. If users then come to us with good use cases for allowing mismatches we can add it later.

I think that breaks with a lot of other patterns in rustc, and the Rust language. A lot of the guardrails have an unsafe/unchecked opt-out mechanism. As long as the consequences are cleary explained, I think this opt-out flag is a good idea.

What's about target features flag?
Like:
-Ctarget-feature="+retpoline-external-thunk"
-Ctarget-feature="+retpoline-indirect-branches"
-Ctarget-feature="+retpoline-indirect-calls"

Those will be parsed into single line in codegen::target_feature option. And we can't, probably, mark whole target_feature option as a target modifier, because there can be abi/vulnerability affecting options or not.

Those should not be allowed in -Ctarget-feature, instead we have a new flag for these options which LLVM calls target features but which we will call by a different term in Rust -- a term such as target modifier.

Those should not be allowed in -Ctarget-feature, instead we have a new flag
What flag should be used instead?

As I said, a new flag. It does not exist yet, so the name is TBD.

authors: Darksonn RalfJung azhogin davidtwco rmsyn


text:
Import the cancelbot repo directly to this repo

Not really any need for it be separate and seems good to consolidate!

FWIW I wouldn't really recommend reviewing the code, it's ancient 1.0-style Rust, still using rustc-serialize (!)

repo: rust-lang/rust-central-station


text:
Translate the "Windows 注意事项" section into Chinese

And standardized indent to 2 spaces; Add spaces around English words.

Thanks!

authors: alexcrichton justinchuby

repo: rust-lang/rust-www


text:
Feature Request: Vertical semicolon when wrapping function chains

I ended up writing this feature request formatted like the Rustfmt options docs. Please let me know if more information is needed or if I somehow missed that this option already exists.
fn_chain_vertical_semicolon
Vertically wrap the semicolon at the end of a vertical function chain.
Pros

Easier to visually scan the leftmost character to see when the method calls stop and the semicolon ends the statement.
IDEs that support single-line commenting don't have to be corrected after commenting out the last line.

e.g. in the false example, an IDE may replace .dolor(); with // .dolor(); and comment out the semicolon causing an error.

Cons

Adds a basically empty line, making code taller than necessary.

Default: I don't know how this is decided. As it is currently unimplemented, the default is false.
Possible Values: true, false

false:
fn main() {
    lorem
        .ipsum()
        .dolor();
}

true:
fn main() {
    lorem
        .ipsum()
        .dolor()
        ;
}

Thanks for sharing your idea. I'll leave this open for a bit, but to be fully transparent, this isn't something we the rustfmt team will ever work on and I don't particularly want to solicit contributions either because I don't think it's worth the extra config option.
If this is something you feel strongly enough about you're welcome to submit a pull request which we'd consider, but otherwise this is unlikely to ever come to fruition.

authors: calebcartwright wormingdead

repo: rust-lang/rustfmt


text:
Custom import reordering

TLDR, for a given config:
group_imports = [
    ["$std::*", "proc_macro::*"],
    ["*"],
    ["my_crate::*", "crate::*::xyz"],
    ["$crate::*"],
]

The following order would be set:
use proc_macro::Span;
use std::rc::Rc;

use rand;

use crate::abc::xyz;
use my_crate::a::B;
use my_crate::A;

use self::X;
use super::Y;
use crate::Z;

This PR also contains three auxiliary patches for proc-macro #[config_type]:

0a462a0 allows one to use #[config_type(skip_derive(Debug, ...))], also impl Copy removed from most of types where unneeded;
1d3e43e is for deriving serde::{Serialize, Deserialize};
b195129 impl Display for singled-fielded enums.

These are not really mandatory but simplify the final commit itself. Probably the proc macro could be refactored further but I think it shall be enough for now.
Implementation notes:

Thanks @dbr for the proposed syntax, the difference is usage of arrays instead of tuples as toml doesn't support these https://github.com/toml-lang/toml/issues/219;
toml does not support fielded enums at all, that's why manual impl Deserialize for GroupImportsTactic is required (https://github.com/toml-rs/toml-rs/issues/302 https://github.com/toml-rs/toml/issues/364);
don't really want to introduce an additional crate for wildcards so regex is basically used with a hack: escape(user_pattern).replace("\\*", ".*"), performance should not be concern here anyway;
group_imports function (i.e for StdExternalCrate) could be re-implemented with group_imports_custom but I would rather prefer leaving it separate;
$crate alias doesn't mean usage of macro-specific $crate import.

Resolves #4693, resolves #4788, resolves #5550

Hint: one may build a group for all crates within the workspace with cargo-metadata:
WORKSPACE_INCLUDES=$(cargo metadata --offline --format-version 1 | jq -r '.workspace_members[]' | awk '{ print $1 }' | sed 's|-|_|' | sed 's|^\(.*\)$|"\1::\*",|' | tr '\n' ' ' | sed 's|, $||')
echo "[${WORKSPACE_INCLUDES}]"

which for example for Rocket produces this:
["rocket::*", "rocket_codegen::*", "rocket_http::*", "rocket_db_pools_codegen::*", "rocket_db_pools::*", "rocket_sync_db_pools_codegen::*", "rocket_sync_db_pools::*", "rocket_dyn_templates::*", "rocket_guide_tests::*"]

Wow, this is exactly what we need! Is there any updates about this?)

@l4l I think you need to rebase your PR to get the tests working.

Found a failing test case:
conf:
group_imports = [
    ["$std::*", "proc_macro::*"],
    ["*"],
    ["workspace*::*"],
    ["$crate::*"],
]

Input:
use std::fmt;

use serde::de;

use workspace_p1::m1;
use workspace_p2::m2;
use workspace_p3 as p3;
use workspace_p4 as p4;

Expected:
use std::fmt;

use serde::de;

use workspace_p1::m1;
use workspace_p2::m2;
use {workspace_p3 as p3, workspace_p4 as p4};

Actual:
use std::fmt;

use serde::de;
use {workspace_p3 as p3, workspace_p4 as p4};

use workspace_p1::m1;
use workspace_p2::m2;

Will probably be useful to add a $pub which covers pub(crate) & pub uses.

For me it works as expected, it's not expected to match xyz with xyz::* (only with xyz or xyz*). However the case for the following conf:
group_imports = [
    ["$std::*", "proc_macro::*"],
    ["*"],
    ["workspace*"],
]

works indeed in a quite unexpected way (there's the same result). There's no simple way to split includes, reorder and then somehow "preserve" original granularity. I don't think this behavior need to be changed. The actual problem here is missing import_granularity (e.g Crate) option which places all of the workspace_p* modules in the third block.

Is there any chance to get this reviewed and merged?
Seems like this has been stuck in limbo for no good reason when it's an excellent feature a lot of us are waiting for 😃

Experience report: I tried this option in a fork of rustfmt in a decently-sized personal project (~18 kLoC) with the following config:
# ...
group_imports = [["*"], ["$crate::*"]]
# ...

I only ran into one surprising "issue": a local module import was treated as an external crate import:
  mod register;
  mod view;

  use glam::{const_vec3, Vec2, Vec3};
  use mountain_river::high_scores::{HighScore, HighScores, HIGH_SCORES_PER_GROUP};
+ pub use register::RegisterHighScore;
  use std::{array, borrow::Cow};
  use triplicata::{
      // ...
  };
-
- pub use register::RegisterHighScore;
  pub use view::ViewHighScores;

Since this feature works by matching on import paths, this doesn't really seem like a bug. This was easily fixed by prepending self:: to both local imports.
Also, note that it moved a reexport into a group containing normal imports. This is slightly unfortunate, but I believe that this is an acceptable price to pay for consistency.
Otherwise, everything seems to have gone quite smoothly!

It seems this PR got forgotten, so kind reminder @ytmimi @calebcartwright
If anything else you needed from me or have any concerns feel free to ping. If it's better to split-out the proc-macro part that's also not a problem.

@l4l thanks for reaching out! I wouldn't say this has been forgotten, it's just been put on the back burner while we tend to some higher priority items. We spent a lot of time getting ready for if-let support, and we just recently released some experimental support for let-chains. The next big ticket item for rustfmt is implementing style_edition to give the project more flexibility moving forward. I hope you understand and I appreciate your patience on this.
In the interim, maybe you can add additional tests to see how this new option interacts with other import options like imports_granularity. If there are any edge cases you can think of having good tests for those would also be helpful. While Caleb and I can't spend time reviewing this right now it doesn't mean that this PR has to go unreviewed. Thank you to everyone who's already chimed in and shared their thoughts. I'd sure welcome reviews from anyone who's interested in seeing this land continue to provide feedback on how this PR could be improved or how the implementation could be simplified. It would definitely be a great help for when Caleb and I are able to revisit this.
I'd also like to add that I understand this is important to you and many others, and I personally think it looks like a cool feature!

Some random drive-by notes:

It would be a nice convenience if a string is interchangeable with a single-item list in the config. That is, group_imports = ["$std", "*"] would act the same as group_imports = [["$std"], ["*"]]
I think regex may be better to use here rather than wildcards because it allows e.g.  myproject_(macros|cli)::.* or rustc_.*. In which case, I think it is better to suggest using .* directly rather than doing replace("*", ".*"), which would turn .* in to ..*
How is the fallback supposed to work? In the opening example:

group_imports = [
    ["$std::*", "proc_macro::*"],
    ["*"],
    ["my_crate::*", "crate::*::xyz"],
    ["$crate::*"],
]

I haven't looked at the algorithm but I assume it's trying to match from most specific to most general somehow. It would be more straightforward IMO to always match first to last, and then add a meta $other or $fallback matcher where everything goes if it isn't picked up by another group. E.g. the above could be written as the following (including my other suggestions):
group_imports = [
    ["$std::.*", "proc_macro::.*"],
    "$other",
    ["my_crate::.*", "crate::.*::xyz"],
    ["$crate::.*"],
]

Very useful PR!
It's possible to use [globset](https://github.com/BurntSushi/ripgrep/tree/master/crates/globset as a frontend to regex engine.
It supports "or" globs (myproject_{macros,cli}::*), cc @tgross35.


text:
Set Target Operating Mode

This sets the Target Operating Mode in the second stage before we enter Long Mode. This tells the firmware that we are only planning to operate in 64-bit mode and will not switch back to Legacy Mode, allowing it to make optimisations that it otherwise wouldn't be able to make safely.
Afaict, this was first implemented by AMD for the Opteron in ~2003, and is documented in section 12.21 of this document. Other docs are sparse, but it should be a nop on processors that don't support the function, and this should handle the error codes correctly (it sets the carry flag if the function is not supported).
While the docs only specify that it allows the BIOS to make optimizations that are not visible to system software, the default mode only allows the processor to run in Legacy Mode, and so I wonder if any firmwares that have SMM bugs in x86_64 mode may be fixed by this - that is just postulation tho
Edit: Travis failure is not related - merging #17 should fix this build as well

@IsaacWoods Thanks for the PRs! From a quick glance the changes look good to me. I'll take a closer look next week, because I'm short on time at the moment.

Thanks @IsaacWoods!

Yep, I have no idea if it has any real effects, but I figured it can't hurt and some OEMs might make use of it

authors: IsaacWoods phil-opp

repo: rust-osdev/bootloader


text:
:recycle: refactor(input and ogc-sys): Dont use CLANG_VERSION anymore and added and refactor stuff to input.rs

Removed the use of CLANG_VERSION environment variable.
Added is_button_down, is_button_held and is_button_up.
Added ir functionality.
Made RawData::Wii an option of wpad_data instead of box.
THIS CHANGES HOW OGC-SYS IS BUILT

The parser for the clang version might have some cases where on some platforms the version might include extra information which can break the build. I'm not sure if we should remove the backup environment variable it just in case this does appear.
The rest looks good though!

Ohhh that is why we make them specify just in case! I will probably revert that then

No bother, ill merge this in now!

authors: FrictionlessPortals ProfElements

repo: rust-wii/ogc-rs


text:
cookies: is &mut self required?

&mut self doesn't seem to be required, as mentioned in #316.
Description
Change cookie trait function signature on get_cookie from &mut self to &self.
Motivation and Context
Tide seems to compile fine without requiring a mutable reference. Unsure why the previous behavior may have been required, but I believe there's little need to require mutability when reading cookie values.
How Has This Been Tested?
Existing tests passed.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

I think we should keep&mut self for set|remove_cookie.

Ping @rustasync/maintainers

This would be a breaking change, but I agree with the assertion in #316: that &mut self doesn't make sense here.

I'm slightly concerned with merging this breaking API change, even though I believe it to be technically more correct. As a consumer of Tide and owner of several applications that will be broken when this change is released, and believe the update is worth applying.
I'll go ahead and merge since I'm no longer the only one frustrated (see #316, where the concern is similar to mine: building authentication middleware). Feel free to comment (or revert) if you feel strongly about requiring mut. I think dropping the requirement will make extracting data much cleaner.

authors: kamyuentse secretfader

repo: rustasync/tide


text:
Switch to Azure Pipelines CI

These travis queues take forever...

Switched to github actions now!

Sweet! Can you fix the CI badge in the README?

Oh oops, indeed!

authors: alexcrichton fitzgen

repo: rustwasm/walrus


text:
"Basic Usage" is failing for me

Hi,
Awesome project! I wanted to try it out, but if failed for me.
$ rustup --version
rustup 1.11.0 ( )
$ cargo --version
cargo 1.26.0-nightly (b70ab13b3 2018-04-04)
$ wasm-bindgen --version
wasm-bindgen 0.2.0
$ rustc --version
rustc 1.27.0-nightly (48fa6f963 2018-04-05)

I followed the instructions in "Basic Usage". This is what happened
$ cargo build --target wasm32-unknown-unknown
   Compiling proc-macro2 v0.3.3
error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
  --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:63:41
   |
63 |                 let group = proc_macro::TokenNode::Group(delim, tt.stream.inner.0);
   |                                         ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
  --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:71:47
   |
71 |                 (tt.span().inner, proc_macro::TokenNode::Op(tt.op(), kind))
   |                                               ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
  --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:73:64
   |
73 |             TokenTree::Term(tt) => (tt.inner.span, proc_macro::TokenNode::Term(tt.inner.term)),
   |                                                                ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
  --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:74:67
   |
74 |             TokenTree::Literal(tt) => (tt.inner.span, proc_macro::TokenNode::Literal(tt.inner.lit)),
   |                                                                   ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:122:25
    |
122 |             proc_macro::TokenNode::Group(delim, s) => {
    |                         ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:134:25
    |
134 |             proc_macro::TokenNode::Op(ch, kind) => {
    |                         ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:143:25
    |
143 |             proc_macro::TokenNode::Term(s) => {
    |                         ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0433]: failed to resolve. Could not find `TokenNode` in `proc_macro`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:149:25
    |
149 |             proc_macro::TokenNode::Literal(l) => {
    |                         ^^^^^^^^^ Could not find `TokenNode` in `proc_macro`

error[E0574]: expected struct, variant or union type, found enum `proc_macro::TokenTree`
  --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:77:13
   |
77 |             proc_macro::TokenTree {
   |             ^^^^^^^^^^^^^^^^^^^^^ not a struct, variant or union type

error[E0412]: cannot find type `TokenTreeIter` in module `proc_macro`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:104:38
    |
104 | pub struct TokenTreeIter(proc_macro::TokenTreeIter);
    |                                      ^^^^^^^^^^^^^ did you mean `TokenTree`?
help: possible candidate is found in another module, you can import it into scope
    |
3   | use imp::TokenTreeIter;
    |

error[E0277]: the trait bound `proc_macro::TokenStream: std::iter::FromIterator<imp::TokenStream>` is not satisfied
  --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:88:29
   |
88 |         TokenStream(streams.collect::<proc_macro::TokenStream>())
   |                             ^^^^^^^ a collection of type `proc_macro::TokenStream` cannot be built from an iterator over elements of type `imp::TokenStream`
   |
   = help: the trait `std::iter::FromIterator<imp::TokenStream>` is not implemented for `proc_macro::TokenStream`

error[E0369]: binary operation `==` cannot be applied to type `proc_macro::Span`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:217:17
    |
217 | pub struct Span(proc_macro::Span);
    |                 ^^^^^^^^^^^^^^^^^
    |
    = note: an implementation of `std::cmp::PartialEq` might be missing for `proc_macro::Span`

error[E0369]: binary operation `!=` cannot be applied to type `proc_macro::Span`
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:217:17
    |
217 | pub struct Span(proc_macro::Span);
    |                 ^^^^^^^^^^^^^^^^^
    |
    = note: an implementation of `std::cmp::PartialEq` might be missing for `proc_macro::Span`

error[E0277]: the trait bound `proc_macro::Span: std::cmp::Eq` is not satisfied
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:217:17
    |
217 | pub struct Span(proc_macro::Span);
    |                 ^^^^^^^^^^^^^^^^^ the trait `std::cmp::Eq` is not implemented for `proc_macro::Span`
    |
    = note: required by `std::cmp::AssertParamIsEq`

error[E0599]: no function or associated item named `intern` found for type `proc_macro::Term` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:280:19
    |
280 |             term: proc_macro::Term::intern(string),
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Term`

error[E0599]: no function or associated item named `u8` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `u16` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `u32` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `u64` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `usize` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `i8` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `i16` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `i32` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `i64` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `isize` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `f32` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `f64` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:313:27
    |
313 |               Literal::_new(proc_macro::Literal::$kind(n))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
334 | /     suffixed_numbers! {
335 | |         u8_suffixed => u8,
336 | |         u16_suffixed => u16,
337 | |         u32_suffixed => u32,
...   |
347 | |         f64_suffixed => f64,
348 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `integer` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:321:27
    |
321 |               Literal::_new(proc_macro::Literal::integer(n as i128))
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`
...
350 | /     unsuffixed_integers! {
351 | |         u8_unsuffixed => u8,
352 | |         u16_unsuffixed => u16,
353 | |         u32_unsuffixed => u32,
...   |
360 | |         isize_unsuffixed => isize,
361 | |     }
    | |_____- in this macro invocation

error[E0599]: no function or associated item named `float` found for type `proc_macro::Literal` in the current scope
   --> /Users/mroberts/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.3.3/src/unstable.rs:368:23
    |
368 |         Literal::_new(proc_macro::Literal::float(f))
    |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `proc_macro::Literal`

error: aborting due to 29 previous errors

Some errors occurred: E0277, E0369, E0412, E0433, E0574, E0599.
For more information about an error, try `rustc --explain E0277`.
error: Could not compile `proc-macro2`.

To learn more, run the command again with --verbose.

Heh I think you tested this out in the 15 minute window where this wasn't working, but should be fixed now!

It works! :-)

authors: alexcrichton markandrus

repo: rustwasm/wasm-bindgen


text:
How do I use this program?

Can someone tell me how to even use it? Ive downloaded it and run the executable. Im on windows 10.
The config file is empty. When I run warpd.exe --list-keys or warpd.exe  --list-options it just starts the program without output. How can I determine what keys I need to press to activate it? The readme doesn't seem to mention them? Also does anyone have an example of what a config file looks like? Ill probably want to change the default activation keys.
Thanks

Can someone tell me how to even use it? Ive downloaded it and run the executable. Im on windows 10. The config file is empty.

Config file is to override default options, that's why it's empty.

When I run warpd.exe --list-keys or warpd.exe --list-options it just starts the program without output.

I just tested, and apparently it only works when you pass it -f option. Apparently some bug.

How can I determine what keys I need to press to activate it? The readme doesn't seem to mention them?

It does.

Also does anyone have an example of what a config file looks like? Ill probably want to change the default activation keys. Thanks

Just a few hours ago I stumbled upon the same problem. I provided an example here, but due to a bug it's mostly useless. Well, not completely useless, you can use it to disable some combinations, but actually changing the hotkey doesn't work.

repo: rvaiya/warpd


text:
Unable to build the project

Hello,
I am trying to build the project, but am unable to do so. I have the gnu fortran compiler (version 11.3.0) and the default settings in the makefile did not work so I tried with other settings (which were commented out in the makefile itself). In every case, the build process stopped. I also tried using the settings I had for the original Xcompact3d (which is working without any issues), but still could not get the project to be built. I have attached the makefile and the errors I am facing here. I wanted to know if there is some requirement I need to download or is the fault due to the compiler settings I have.
log.txt
Makefile.txt
Any help would be much appreciated.
Thanks,
Ayush.

Hello,
Thank you for reporting this issue. Indeed, depending on the compilation options, the compiler may reject the computation of the variable c1 as it was previously done in the subroutine set_viscfilter_coefficients. In 630d7c2079ce65dc5d197c1543a783fde6731274, I've implemented its direct value c1=0.44, as it is done in the file input.i3d (variable cnu). Could you please try to recompile ?

I am able to compile it now without any issues
Thanks for the speedy reply
Regards,
Ayush.


text:
F32

This branch:

Replace f64 with f32 for a smaller memory footprint
Maps each vocab word into a unique usize value, so that we can have both better hashmap performance and a more compact token representation in the doc cluster count maps.

Closing in favor of https://github.com/rwalk/gsdmm-rust/pull/4

repo: rwalk/gsdmm-rust

license: mit


text:
sh - false postive on closing quote

Hello, prettier-plugin-sh seems to be giving me a false positive:
lolaus.sh
[error] lolaus.sh: SyntaxError: reached EOF without closing quote "
[error]   186 | }
[error]   187 |
[error] > 188 | main "$@"
[error]       |         ^
[error]   189 |

Here is a gist of the script. I can not found a missing quote or bracket. The script runs fine and passes shellcheck, maybe there is still an error in the script but it seems there is potential it is in the plug-in.
Any pointers? And thanks.

Sorry for the delay first, I tried mvdan-sh's latest go tool, it is working correctly.
But its js module is outdated, let wait for the original author first.

authors: JounQin tomdavidson

repo: rx-ts/prettier


text:
hey man I'm really stupid

how do i do it on chromebook?

nevermind i figured it out

repo: rxzyx/prodigy-hack


text:
Anywhere to buy these currently?

CrowdSupply won't even let me place a preorder. :-/

https://eu.mouser.com/ProductDetail/392-CS-PDMICRO-01

Any clarity on when (or even if) that might be fufilled?

authors: awesome-manuel ryancdotorg


text:
Create models

Idea
Create models needed for the site to function properly.
Todo

[ ] model 1

Determining which models are needed

Using the site from #4


text:
Just audio wavefrom

You took and immediately closed my problem.  And the Internet does not have any information about how to connect these two plugins.  There is no such question on Stackoverflow and ChatGpt doesn't know your plugin.  Can you share the code?  I don't think it's that much of a problem for you.  There is no documentation about it at all.  Yes, I'm new to programming. And how to deal with this issue?

Closing and locking. I tried to help you in your previous issue by pointing you to the correct place to ask questions. GitHub is for reporting issues, and you have not pointed out an actual issue in the plugin that needs to be fixed.
If it was not clear from the previous issue, it is not my job to teach you how to program, and you should not assume how much of a burden you would be placing on me by demanding that I teach you programming by spamming the same question multiple times.
If you decide create a third issue despite my previous reply, I will unfortunately have to block you, so please don't do that and seek programming help in the places you were already advised in your last so-called "issue".

authors: ara-chinaryan ryanheise


text:
🛑 Backend is down

In 5243c78, Backend ($SECRET_BACKEND_SITE) was down:

HTTP code: 502
Response time: 905 ms

Resolved: Backend is back up in 89bbf32.

repo: ryanlid/upptime


text:
classwork02

Петров Михаил

Coverage decreased (-41.2%) to 30.769% when pulling 98efeb7f5ce81009a4de459c7ae980ad080969bf on ololo3000:lecture02 into dd9be1b5d62de9c856c3cb5c0e78abdf975d50e0 on rybalkinsd:lecture02.

Coverage increased (+8.3%) to 80.342% when pulling d185094c287a0917608806586dadf707a3063185 on ololo3000:lecture02 into dd9be1b5d62de9c856c3cb5c0e78abdf975d50e0 on rybalkinsd:lecture02.

@ololo3000
Проходит все тесты (BarBarCollisionTest, BarPointCollisionTest & PointPointCollisionTest).
Получается 5 баллов. @rybalkinsd

authors: coveralls ilya-lysko ololo3000

repo: rybalkinsd/atom


text:
🛑 PeriodO data is down

In c7128e1, PeriodO data (https://data.perio.do) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PeriodO data is back up in 821f1cf after 7 minutes.

repo: rybesh/status


text:
programs.feh.keybindings does not support multiple keys for one value

in feh, you can have more than one key corresponding to the same action, but in Nix home manager programs.feh.keybindings you can only have one value per action (one key only)

A bit of a hack, but what has worked for me is to just put multiple keys, separated with whitespace, in the string for a command. E.g.
{
  programs.feh.keybindings = {
    menu_parent = "h Left";
    menu_down = "j Down";
    menu_up = "k Up";
    menu_child = "l Right";

    prev_img = "h Left";
    next_img = "l Right";

    zoom_out = "j Down";
    zoom_in = "k Up";
  };
}

authors: eyadsibai olmokramer

repo: rycee/home-manager


text:
Use attrsOf instead of attrs

Replaces some unnecessary use of types.attrs.

Thanks for having a look! Rebased to master now.


text:
investigate using Treiber Stack

I think this would be almost a perfect replacement for the mutex of vec T, as it's generic over T and can be put in an Arc without any issues!
Unfortunately it's not a standalone module, but we could easily copy it over into our source.
https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-epoch/examples/treiber_stack.rs

This is fixed with #5

authors: rylev yoshuawuyts

repo: rylev/remem


text:
[BUG] NPE on @SuperBuilder HandleSuperBuilder.constructorExists(HandleSuperBuilder.java:1198)

Describe the bug
I'm getting a nullPointerException when I have a @SuperBuilder and also have a default, no args, costructor.
This only happens on Eclipse! Both IntelliJ and VSCode behaves fine with the same code
To Reproduce
Have the following classes on Eclipse IDE
Parent.java
import lombok.Data;
import lombok.EqualsAndHashCode;
import lombok.NoArgsConstructor;
import lombok.experimental.SuperBuilder;

@Data
@EqualsAndHashCode(onlyExplicitlyIncluded = true)
@NoArgsConstructor
@SuperBuilder
public abstract class Parent {

  int a;
  String b;
  String type;

}

Child.java
import java.util.ArrayList;
import java.util.List;
import lombok.Builder;
import lombok.Data;
import lombok.EqualsAndHashCode;
import lombok.experimental.SuperBuilder;

@Data
@EqualsAndHashCode(callSuper = true)
@SuperBuilder
public class Child extends Parent {

  public Child() {
    this.type = "C";
  }

  @Builder.Default
  List<Integer> c = new ArrayList<>();
}

Expected behavior
Child class to have a .builder() method.
Current Behavior
!ENTRY org.eclipse.jdt.core 4 0 2021-01-06 16:51:38.377 !MESSAGE Lombok annotation handler class lombok.eclipse.handlers.HandleSuperBuilder failed !STACK 0 java.lang.NullPointerException 	at lombok.eclipse.handlers.HandleSuperBuilder.constructorExists(HandleSuperBuilder.java:1198) 	at lombok.eclipse.handlers.HandleSuperBuilder.handle(HandleSuperBuilder.java:316) 	at lombok.eclipse.HandlerLibrary$AnnotationHandlerContainer.handle(HandlerLibrary.java:106) 	at lombok.eclipse.HandlerLibrary.handleAnnotation(HandlerLibrary.java:237) 	at lombok.eclipse.TransformEclipseAST$AnnotationVisitor.visitAnnotationOnType(TransformEclipseAST.java:267) 	at lombok.eclipse.EclipseNode.traverse(EclipseNode.java:107) 	at lombok.eclipse.EclipseAST.traverseChildren(EclipseAST.java:233) 	at lombok.eclipse.EclipseNode.traverse(EclipseNode.java:74) 	at lombok.eclipse.EclipseAST.traverseChildren(EclipseAST.java:233) 	at lombok.eclipse.EclipseNode.traverse(EclipseNode.java:69) 	at lombok.eclipse.EclipseAST.traverse(EclipseAST.java:226) 	at lombok.eclipse.TransformEclipseAST.go(TransformEclipseAST.java:224) 	at lombok.eclipse.TransformEclipseAST.transform(TransformEclipseAST.java:185) 	at lombok.eclipse.TransformEclipseAST.transform_swapped(TransformEclipseAST.java:110) 	at jdk.internal.reflect.GeneratedMethodAccessor45.invoke(Unknown Source) 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 	at java.base/java.lang.reflect.Method.invoke(Method.java:566) 	at lombok.launch.PatchFixesHider$Util.invokeMethod(PatchFixesHider.java:119) 	at lombok.launch.PatchFixesHider$Transform.transform_swapped(PatchFixesHider.java:190) 	at org.eclipse.jdt.internal.compiler.parser.Parser.endParse(Parser.java:11687) 	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:12880) 	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13104) 	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13061) 	at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:144) 	at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:100) 	at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:755) 	at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProject(IndexBasedHierarchyBuilder.java:265) 	at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(IndexBasedHierarchyBuilder.java:350) 	at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:166) 	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:323) 	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1319) 	at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:94) 	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:740) 	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:806) 	at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:950) 	at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:907) 	at org.eclipse.jdt.internal.ui.javaeditor.codemining.JavaImplementationCodeMining.countMethodImplementations(JavaImplementationCodeMining.java:195) 	at org.eclipse.jdt.internal.ui.javaeditor.codemining.JavaImplementationCodeMining.lambda$0(JavaImplementationCodeMining.java:105) 	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736) 	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728) 	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) 	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) 	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) 	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) 	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Version info (please complete the following information):

Lombok v1.18.16 "Envious Ferret" is installed.
Platform Eclipse IDE for Enterprise Java Developers (includes Incubating components) Version: 2020-12 (4.18.0) Build id: 20201210-1552

FYI
I've managed to fix this by adding a null check on that line and adding a new if condition for no args constructor like so:
			```
...
    if (def.arguments==null  ||  def.arguments.length < 1) continue;
if (def.arguments!=null && def.arguments.length != 1) continue;
    ...

FYI
I've managed to fix this by adding a null check on that line and adding a new if condition for no args constructor like so:
			```
...
    if (def.arguments==null  ||  def.arguments.length < 1) continue;
if (def.arguments!=null && def.arguments.length != 1) continue;
    ...

Can confirm.
Changing the failing line to if (def.arguments == null || def.arguments.length != 1) continue; should fix this.

Can confirm.
Changing the failing line to if (def.arguments == null || def.arguments.length != 1) continue; should fix this.

Similar reproduce scenario:
import lombok.Getter;
import lombok.NonNull;
import lombok.experimental.SuperBuilder;

public class LombokTest {

	public static void main(String[] args) {
		ConcreteClass cc = new ConcreteClass();
		System.out.println("cc name: " + cc.getName());
	}

	@SuperBuilder
	public static abstract class AbstractParentClass {
		@Getter @NonNull
		private final String name;
	}

	@SuperBuilder
	public static class ConcreteClass extends AbstractParentClass {
		public ConcreteClass() {
			this("default_name");
		}

		public ConcreteClass(String myName) {
			super(builder().name(myName));
		}
	}
}

Looking forward to the fix to be included in next version. Thank you for all your help!

Similar reproduce scenario:
import lombok.Getter;
import lombok.NonNull;
import lombok.experimental.SuperBuilder;

public class LombokTest {

	public static void main(String[] args) {
		ConcreteClass cc = new ConcreteClass();
		System.out.println("cc name: " + cc.getName());
	}

	@SuperBuilder
	public static abstract class AbstractParentClass {
		@Getter @NonNull
		private final String name;
	}

	@SuperBuilder
	public static class ConcreteClass extends AbstractParentClass {
		public ConcreteClass() {
			this("default_name");
		}

		public ConcreteClass(String myName) {
			super(builder().name(myName));
		}
	}
}

Looking forward to the fix to be included in next version. Thank you for all your help!

authors: AndreBritoKD gypsy janrieke

repo: rzwitserloot/lombok


text:
[BUG] @Jacksonized does not copy @JsonUnwrapped to @Builder

Describe the bug
The @Jacksonized annotation says it "[copies] Jackson-related configuration annotations [...] from the class to the builder class."  However, it does not copy the @JsonUnwrapped annotation, which results in incorrect deserialization behavior for objects that require it.
To Reproduce
ExampleFile.java
import com.fasterxml.jackson.annotation.JsonUnwrapped;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.*;
import com.fasterxml.jackson.databind.json.JsonMapper;
import lombok.*;
import lombok.extern.jackson.Jacksonized;

public class ExampleFile {
    public static void main(String[] args) throws JsonProcessingException {
        ObjectMapper objectMapper = JsonMapper.builder().disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES).build();
        WithUnwrapped expected = new WithUnwrapped(new NestedValue("A", "B"));

        String json = "{\"value1\":\"A\",\"value2\":\"B\"}";
        WithUnwrapped deserializedObject = objectMapper.readValue(json, WithUnwrapped.class);
        if (!expected.equals(deserializedObject)) {
            throw new IllegalStateException("Wrong value; was: " + deserializedObject);
        }
    }

    @Data
    @NoArgsConstructor
    @AllArgsConstructor
    @Builder     // Correct result if these two annotations are commented out
    @Jacksonized // Correct result if these two annotations are commented out
    public static class WithUnwrapped {
        @JsonUnwrapped
        private NestedValue nested;
    }

    @Data
    @NoArgsConstructor
    @AllArgsConstructor
    public static class NestedValue {
        private String value1;

        private String value2;
    }
}

Reproduction Steps
$ curl -s https://repo1.maven.org/maven2/org/projectlombok/lombok/1.18.18/lombok-1.18.18.jar -O
$ curl -s https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.12.1/jackson-annotations-2.12.1.jar -O
$ curl -s https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.12.1/jackson-core-2.12.1.jar -O
$ curl -s https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.12.1/jackson-databind-2.12.1.jar -O
$ javac -cp "*" ExampleFile.java
$ java -cp ".:*" ExampleFile
Exception in thread "main" java.lang.IllegalStateException: Wrong value; was: ExampleFile.WithUnwrapped(nested=null)
	at ExampleFile.main(ExampleFile.java:17)

Expected behavior
The @JsonUnwrapped annotation should be copied to the builder method.  In the specific example above, this should lead to the JSON value successfully parsing.
Version info (please complete the following information):

Lombok 1.18.18
javac 11.0.9.1

I have been facing the same issue with my use case and I took a look at the JacksonizedHandler.
It uses the array defined in HandlerUtils with the following members:
JACKSON_COPY_TO_BUILDER_ANNOTATIONS = Collections.unmodifiableList(Arrays.asList(new String[] {
			"com.fasterxml.jackson.annotation.JsonAutoDetect",
			"com.fasterxml.jackson.annotation.JsonFormat",
			"com.fasterxml.jackson.annotation.JsonIgnoreProperties",
			"com.fasterxml.jackson.annotation.JsonIgnoreType",
			"com.fasterxml.jackson.annotation.JsonPropertyOrder",
			"com.fasterxml.jackson.annotation.JsonRootName",
			"com.fasterxml.jackson.annotation.JsonSubTypes",
			"com.fasterxml.jackson.annotation.JsonTypeInfo",
			"com.fasterxml.jackson.annotation.JsonTypeName",
			"com.fasterxml.jackson.annotation.JsonView",
			"com.fasterxml.jackson.databind.annotation.JsonNaming",
		}));

Wouldn't the fix be as simple as adding "com.fasterxml.jackson.annotation.JsonView" to this array?

Probably not, because that list is for the builder class, not the setter methods. However, there's another list for that: COPY_TO_SETTER_ANNOTATIONS

I just realized the sample above is a bit different from our case.
Our case is something like this:
@Builder
@Jacksonized
public class Foo {
    @JsonUnwrapped
    Bar other;
}

If I manually add a builder and annotate the Bar-method as JsonUnwrapped it works as expected.
In this case the suggestion above should be valid, right?

Or is it that you mean to say that the JACKSON_COPY_TO_BUILDER_ANNOTATIONS enumerates the annotations that would end up on the actual Builder class and the COPY_TO_SETTER_ANNOTATIONS enumerates annotations that would end up on the actual setter method of the class?

Exactly.

Any updates on this @snystedt @janrieke ?

@snystedt I don't use any of these tools so I have to go by what you've all figured out. I don't know what @JsonUnwrapped is meant to do. However, if indeed it is the case that it should always be copied straight to the builder's 'setter' method if the field is annotated with it, then yeah, it's as simple as adding it to the list for the COPY_TO_SETTER_ANNOTATIONS file. If you're a new contributor, also add yourself to the AUTHORS file and that's all that's needed in the PR for this one I think.

authors: j-klemm janrieke mjustin rzwitserloot snystedt


text:
ScrollZoom not working

ScrollZomm isn't working in FF 66.0.2 with 2.0.0-beta5.
I narrowed down the problem to e.wheelDelta not e.detail not beeing available here:
https://github.com/s-yadav/iv-viewer/blob/master/lib/ImageViewer.js#L613
My quick fix would be to change it to e.deltaY

Fixed this as suggested on v2.0.0. Let me know if that works.

authors: Dee-Fuse s-yadav

repo: s-yadav/iv-viewer


text:
Turing self-evaluation

:white_check_mark: Checklist

[x] This pull request has a meaningful title.
[x] If your changes are not yet ready to merge, you have marked this pull request as a draft pull request.

:ballot_box_with_check: Maintainers' checklist

[ ] This pull request has had the appropriate labels assigned
[ ] This pull request has been added to the SATRE backlog project board
[ ] This pull request has been assigned to one or more maintainers

:arrow_heading_up: Summary

:closed_umbrella: Related issues

In progress Turing self-evaluation

:raising_hand: Acknowledging contributors

[x] All contributors to this pull request are already named in the table of contributors in the README file.
[x] The following people should be added to the table of contributors in the README file:

@craddm @JimMadge @edwardchalstrey1 @harisood : What do you think of the formatting of our answers here? Do you think the table layout is a good one or would you prefer something else?

LGTM

Looks good! I have some thoughts:

Could we separate out our Response points into bulletpoints? Might then make it easier for others to quickly check against
Can we read it left to right as 'Score', 'Response', 'Potential improvements', might read a bit better
When we score at this level (by statement), what is next? Is that it, or do we e.g. take an average to give us a score for the grouped thing (e.g. Requirements gathering and monitoring) the capability (e.g. Governance requirements) or something else?

Agree with @harisood's suggestion to reorder the columns, and that bulletpointing might help readability. Otherwise, yes, table seems good!

I think the table gets a bit cramped with paragraphs.
I assume that an unordered list inside a table cell is not possible, but would also probably look odd.
Maybe what we really want is the text as a report, with sections mirroring the spec, and a summary table (or tables) to quickly view the scores?

1. Information Governance
1.1. Governance Requirements
1.1.1.
Score
1
Response
...
Potential Improvements
...
Summary

score

1.1.1
1

mode (excluding optional)

So it turns out that you can put bullet points inside a table. That would look a bit like this:

@JimMadge's suggestion would look something like this (we could add bullet points but I haven't done so here).

Here's another option:

Bullet points in the table doesn't look too bad.
I think having tables could help with summaries like mode score for section x or mode score overall. I think we spoke about using metrics like that.
I think it looks better outside of a table though (and is probably easier to write?).
How does the last option work? Looks a bit wonky with the score and bullet points not lining up.

@JimMadge : last option uses MyST fieldlists

Another option: move the "Potential Improvements" into a new row on its own:

Another option to increase available width: move the "Potential Improvements" into a new row on its own:
or a subsection within an existing row

Not keen on either of these.

I think unstructured maybe reads a bit better, but would be concerned it turns into a reaaaaally long dense body of text, in a way that feels less threatening when a table?

authors: JimMadge craddm edwardchalstrey1 harisood jemrobinson

repo: sa-tre/satre-specification


text:
Add documentation for API Status Kind

Closes #2974
CC @bgrant0607

Ignore

repo: saad-ali/kubernetes