A retry and backoff mechanism for `std::future::Future`
Exponential backoff and retry for Rust.
QuickCheck bug hunting in Rust standard library data structures
The Rust package manager
manage cargo cache (${CARGO_HOME}, ~/.cargo/), print sizes of dirs and remove dirs selectively
Detects usage of unsafe Rust in a Rust crate and its dependencies.
jakubadamw/charaka-hugo-theme 0
Minimalistic and Responsive blog theme for hugo
CommonMark parsing and rendering library and program in C
pull request commentrust-lang/rust
@JohnTitor, @petrochenkov, uh, I am really sorry for the breakage. :( My bad!
comment created time in a day
issue closedjakubadamw/rutenspitz
Testing methods that accept slices is undocumented
It is very easy to test methods that return a slice - all I have to write is:
equal {
fn as_mut_slice(&mut self) -> &mut [T];
}
and rutenspitz takes care of the rest. However, methods accepting slices fail with cryptic errors:
equal {
fn extend_from_slice(&mut self, sli: &[T]);
}
gives:
error[E0277]: the size for values of type `[T]` cannot be known at compilation time
--> fuzz/src/bin/tinyvec.rs:29:51
|
29 | fn extend_from_slice(&mut self, sli: &[T]);
| ^^^ doesn't have a size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `[T]`
= note: no field of an enum variant may have a dynamically sized type
= help: change the field's type to have a statically known size
help: borrowed types always have a statically known size
|
29 | fn extend_from_slice(&mut self, sli: &&[T]);
| ^
help: the `Box` type always has a statically known size and allocates its contents in the heap
|
29 | fn extend_from_slice(&mut self, sli: &Box<[T]>);
| ^^^^ ^
Using &&[T] complains about lifetimes. &Box<[T]> works; it would be nice to document this somewhere - or even better, relax this restriction.
closed time in 4 days
Shnatsel
issue commentjakubadamw/rutenspitz
Testing methods that accept slices is undocumented
@Shnatsel, thanks for the report!
Well, I think unsized types such as slices deserve special casing for convenience, so I did just that in 203f8da22e.
comment created time in 4 days
push eventjakubadamw/rutenspitz
commit sha 203f8da22ec3c5a8b56b7f3544d615ef3232b25c
Add special-casing for slices as arguments to fuzzed operations
push time in 4 days
pull request commentrust-fuzz/trophy-case
@Shnatsel, thank you, I'm honored! 🙂
comment created time in 6 days
pull request commentLokathor/tinyvec
Fuzz: drop workarounds for operations that may panic
@Shnatsel, I used a regular lldb (HFUZZ_DEBUGGER=lldb cargo hfuzz run-debug …). In fact, I had issues with rust-lldb. 🙂 But yes, it is written with lldb in mind and perhaps could use some clarification.
comment created time in 7 days
pull request commentLokathor/tinyvec
Fuzz: drop workarounds for operations that may panic
LGTM. 👍
comment created time in 7 days
push eventjakubadamw/projects
commit sha 04bc71bbd84fab228f0c245981006c140162f10f
Update the name of one crate to the new one
push time in 7 days
pull request commentjakubadamw/rutenspitz
@Shnatsel, this is fixed now. Try updating to 0.2.1.
comment created time in 7 days
created tagjakubadamw/rutenspitz
А procedural macro to be used for testing/fuzzing stateful models against a semantically equivalent but obviously correct implementation
created time in 7 days
push eventjakubadamw/rutenspitz
commit sha 94934ea9b8e627da9bd4644554cf1a0d01b4aa17
Clippy.
commit sha c3761a6f09a102a4957ce8c981fa085bc67613c3
0.2.1
push time in 7 days
push eventjakubadamw/rutenspitz
commit sha 97d27d2a36fdc76d6572b1b271fdccced82f3f15
Install a panic hook to ignore panics within the catch_unwind closures While we're at it, split up the crates into two such that the other captures all the use-side dependencies, to make the macro a little more forward-compatible.
push time in 7 days
pull request commentjakubadamw/rutenspitz
@Shnatsel, indeed, adding a std::panic::take_hook(); to the fuzz cycle solves the issue, though we really ought to install a hook that ignores the panics from within the closures. I'll try to fix this now. 🙂
comment created time in 7 days
pull request commentjakubadamw/rutenspitz
@Shnatsel, oh dear. Yeah, this should have been tested. 🙂
It seems like https://github.com/rust-fuzz/honggfuzz-rs/blob/master/src/lib.rs#L261-L271 is the culprit. It won't be hard to update the hook such that it does not abort on panics arising from within the inner closures.
On the other hand, honggfuzz-rs does not install the hook in the debug mode, where I am also seeing an abort, which is strange.
comment created time in 7 days
startedservo/rust-smallvec
started time in 7 days
issue commentrust-lang/hashbrown
@jonhoo, I'm the maintainer of that project (which now has a proper name: rutenspitz), so if I could be of any assistance, please do cc me. :)
In the past I have used it to fuzz hashbrown, which is when I found the issue #113. I was however deemed the expected behavior. 🙂 The fuzzer can nonetheless be used as part of a regression suite, perhaps.
comment created time in 7 days
Pull request review commentLokathor/tinyvec
Fix the fuzzers that stopped compiling
impl<T> RangeBounds<T> for ArbRange<T> { } impl<T: Arbitrary> Arbitrary for ArbRange<T> {
The whole impl can be removed in favour of a simple #[derive(Arbitrary)], as soon as a new version of arbitrary is released.
comment created time in 8 days
push eventjakubadamw/tinyvec
commit sha 73df2c640868faf4a286ec22d0a12d1881900fdb
Fix the fuzzers that stopped compiling
push time in 8 days
startedByron/git-oxide
started time in 10 days
issue commentrust-lang/rust
Inifinite loop in try_push_visible_item_path
This seems to be fixed. I verified both with the test case above and using the repro script from https://github.com/rust-lang/rust/issues/58430#issue-409902389.
@rustbot modify labels to +E-needs-test
comment created time in 10 days
startedWilltor/forkscan
started time in 10 days
issue commentrust-lang/rust
ICE with the `(foo @ ..,)` pattern
@petrochenkov, this would normally be invalid syntax, much like in this case. The only reason it is accepted as far as the parsing, resolve and/or AST lowering is so that the error message is more informative. Therefore, while the syntactic form is carried over further into the compiler pipeline for this very purpose, it seems reasonable to reject/ignore some of its effects (like, indeed, not resolve the binding it introduces) as early as possible. Or perhaps I'm missing something?
This isn't to say the fix was ideal, which #74692 demonstrates. 🙂 Sorry for that!
comment created time in 12 days
push eventjakubadamw/rosjainflagranti
commit sha f2fe01d8690d5d080b6278c76d61d9399c35be47
Update Zbrodnia i kara (2007).md
push time in 12 days
push eventjakubadamw/pest
commit sha 4fcdcfba2d57176f504fd0e1e176df1d10c33c28
Bump `sha-1` to 0.9.
push time in 13 days
push eventjakubadamw/rosjainflagranti
commit sha 541b5fe2595f17f1e81f176ca28e1858b71624b4
Update Zbrodnia i kara (2007).md
push time in 15 days
startedAegisub/Aegisub
started time in 15 days
created tagjakubadamw/rutenspitz
А procedural macro to be used for testing/fuzzing stateful models against a semantically equivalent but obviously correct implementation
created time in 15 days
push eventjakubadamw/rutenspitz
commit sha 4bcc90369f5e2afed5dc19848c70852643bfac86
0.2.0
push time in 15 days
issue closedjakubadamw/rutenspitz
Test that operations equivalently panic
It would be useful to be able to specify that some methods are expected to sometimes panic, then have the running of those methods be wrapped in catch_unwind and the result of that compared to ensure both implementations either panic, or return the same result.
It may or may not be possible to continue running other operations after the methods panic, so these might need to be tagged somehow as to whether the data structure/operation is RefUnwindSafe.
closed time in 15 days
Nemo157
issue commentjakubadamw/rutenspitz
Test that operations equivalently panic
Closed by #7.
comment created time in 15 days
pull request commentjakubadamw/rutenspitz
Also compare panicking behavior
@Shnatsel, thanks again! ❤️ I'll close this now that #6 and #7 are merged in.
comment created time in 15 days
PR closed jakubadamw/rutenspitz
I've attempted to implement #2 but ended up in a weird lifetime hell, and could not resolve it by myself. I'm opening a WIP PR so that someone else might get a better starting point if they try to implement this.
The error is:
error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
--> src/tests/index_map.rs:168:16
|
168 | fn values_mut(&mut self) -> impl Iterator<Item = &mut V>;
| ^^^^^^^^^^
|
note: first, the lifetime cannot outlive the lifetime `'_` as defined on the body at 135:1...
--> src/tests/index_map.rs:135:1
|
135 | arbitrary_stateful_operations! {
| _-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
136 | | model = ModelHashMap<K, V>,
137 | | tested = IndexMap<K, V>,
138 | |
... |
170 | | }
171 | | }
| |_- in this macro invocation
note: ...so that closure can access `model`
--> src/tests/index_map.rs:135:1
|
135 | / arbitrary_stateful_operations! {
136 | | model = ModelHashMap<K, V>,
137 | | tested = IndexMap<K, V>,
138 | |
... |
170 | | }
171 | | }
| | ^ in this macro invocation
| |_|
|
note: but, the lifetime must be valid for the call at 135:1...
--> src/tests/index_map.rs:135:1
|
135 | / arbitrary_stateful_operations! {
136 | | model = ModelHashMap<K, V>,
137 | | tested = IndexMap<K, V>,
138 | |
... |
170 | | }
171 | | }
| | ^ in this macro invocation
| |_|
|
note: ...so type `std::result::Result<impl std::iter::Iterator, std::boxed::Box<(dyn std::any::Any + std::marker::Send + 'static)>>` of expression is valid during the expression
--> src/tests/index_map.rs:135:1
|
135 | / arbitrary_stateful_operations! {
136 | | model = ModelHashMap<K, V>,
137 | | tested = IndexMap<K, V>,
138 | |
... |
170 | | }
171 | | }
| | ^ in this macro invocation
| |_|
|
pr closed time in 15 days
issue openedjakubadamw/rutenspitz
Have a mode that crashes on all panics
So with #6 and #7 merged in rutenspitz no longer crashes in a fuzz cycle on a panic when both the implementation and the model panic in accordance. This change in behaviour is fine, since the main purpose of this crate is to observe the equivalence of two models. But I think it may be useful to use it also to find panics on malformed input (well, a series of operations to a model). This is exactly what the url::Url fuzzer fuzzer did, although it did in a rather convoluted way by using url::Url as the supposed doppelganger of url::Url itself.
Rather than doing that we should have a mode which turns of all comparisons, essentially always using https://github.com/jakubadamw/rutenspitz/blob/ff2c1b27cf2adba4d354dcf18e2877a9fc9c4ee5/lib/src/lib.rs#L482-L486 for individual operation tests, without using (and requiring) a model at all.
This is perhaps somewhat out of scope given the name of this crate but nonetheless seems like a useful extension.
created time in 15 days
push eventjakubadamw/rutenspitz
commit sha 04a6f4d81974eabd2fa45d51ac8e6608559652c8
blackmagicery
commit sha 8da1c8110e1ff09c78a25d88bccdee01b7f49bbf
cargo fmt
commit sha 65ad3d30fdb7cd10c4bc7ead5217c8fb6fe72aea
Merge remote-tracking branch 'Soveu/master' into panic-equivalence
commit sha 9a3dc8ac491939770029c43ddd472a47c720b968
A minor clean-up with a fix to the outcome handling logic
commit sha bddb0435ccee0746f374e9b724c1b66dd5bc739d
In the debug mode carry over the debug representations of return values
commit sha b71c119ccf81147ce5738c5e1a538da970dd2e97
Clippy.
commit sha f1f37fffc44468c9453945b3582f0328fbb57ce3
A minor naming correction
commit sha a693cc4cea9dc2f31a5fc5db3eb96df4724085f0
Avoid unnecessary clones
commit sha 97f384e1a807d5865042d05eeeefedd6055a20f2
Merge branch 'master' into panic-equivalence
commit sha 71033c77c96a08cb443b026cfb5469109c17100d
Remove the redundant Clone derive
commit sha ff2c1b27cf2adba4d354dcf18e2877a9fc9c4ee5
Merge pull request #7 from jakubadamw/panic-equivalence Panic equivalence
push time in 15 days
PR merged jakubadamw/rutenspitz
The continuation of #6.
First of all, thank you, @Soveu, for your changes, and @Plecra and @Shnatsel – for your input and past attempts. 🙂
This is essentially a slightly corrected and somewhat cleaned-up version of #6. I also made it carry over the debug representations of compared values when cfg(fuzzing_debug) is enabled.
pr closed time in 15 days
pull request commentjakubadamw/rutenspitz
Yeah, it'd close automatically once I merge that one, which I'll do once it goes green. 🙂
comment created time in 15 days
push eventjakubadamw/rutenspitz
commit sha 71033c77c96a08cb443b026cfb5469109c17100d
Remove the redundant Clone derive
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 9c0a395f837acc2fc7fdd653d89409e7bd6c9422
Fix the fuzz targets in debug mode
commit sha 238fbaf5a003de123e7210b7a039ec87ae4d91f2
Build the targets in debug mode in CI
commit sha e93dbfd7dff095dc1bcc44edb361bfc42c2304e8
Remove cargo-audit, it's not very useful for us
commit sha 97f384e1a807d5865042d05eeeefedd6055a20f2
Merge branch 'master' into panic-equivalence
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha e93dbfd7dff095dc1bcc44edb361bfc42c2304e8
Remove cargo-audit, it's not very useful for us
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha a693cc4cea9dc2f31a5fc5db3eb96df4724085f0
Avoid unnecessary clones
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 9c0a395f837acc2fc7fdd653d89409e7bd6c9422
Fix the fuzz targets in debug mode
commit sha 238fbaf5a003de123e7210b7a039ec87ae4d91f2
Build the targets in debug mode in CI
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha f1f37fffc44468c9453945b3582f0328fbb57ce3
A minor naming correction
push time in 15 days
pull request commentjakubadamw/rutenspitz
@Soveau, thanks very much for this PR, and @Plecra for the input.
I cleaned it up and addressed the issued described in this comment.
comment created time in 15 days
push eventjakubadamw/rutenspitz
commit sha 04a6f4d81974eabd2fa45d51ac8e6608559652c8
blackmagicery
commit sha 8da1c8110e1ff09c78a25d88bccdee01b7f49bbf
cargo fmt
commit sha 65ad3d30fdb7cd10c4bc7ead5217c8fb6fe72aea
Merge remote-tracking branch 'Soveu/master' into panic-equivalence
commit sha 9a3dc8ac491939770029c43ddd472a47c720b968
A minor clean-up with a fix to the outcome handling logic
commit sha bddb0435ccee0746f374e9b724c1b66dd5bc739d
In the debug mode carry over the debug representations of return values
commit sha b71c119ccf81147ce5738c5e1a538da970dd2e97
Clippy.
push time in 15 days
PR opened jakubadamw/rutenspitz
The continuation of #6.
First of all, thank you, @Soveu, for your changes, and @Plecra and @Shnatsel – for your input and past attempts. 🙂
This is essentially a slightly corrected and somewhat cleaned-up version of #6. I also made it carry over the debug representations of compared values when cfg(fuzzing_debug) is enabled.
pr created time in 15 days
push eventjakubadamw/rutenspitz
commit sha dc49da04fc9ef5f964c436d53faf0fefa177c9ca
Add DEBUGGING.md
push time in 15 days
started4iar/lldb-write
started time in 15 days
push eventjakubadamw/rutenspitz
commit sha d77b036b3adeb6b4d833a58e52673b73cc13a48f
Fix capacity for the HashMap
push time in 15 days
pull request commentjakubadamw/rutenspitz
Also compare panicking behavior
@Shnatsel, well, adding .cloned() to the v.get_mut(999) call does the trick. 🙂 Sorry, I of course talked gibberish about the moving, I think I may have forgotten the gist of the issue by now. 🙂 So cloning return values of all operations and moving them out of the closure is one plausible solution. It'd require adding a special trait because we can't just Clone: for Option values, for example, we need the inner value cloned (via the cloned() method, indeed). Then the're the special handling of iterators… And it'll make the whole fuzzing process slower. But it's doable.
I can take a look. 🙂
comment created time in 15 days
pull request commentjakubadamw/rutenspitz
Also compare panicking behavior
@Shnatsel, apologies for not getting back to you about this PR. I had looked at it briefly. The problem is the way the PR is written we're moving the instance of the structure being tested into the closure, which we can't do because there's only one of it. I think we'd have to store it in a RefCell to make it work but maybe I'm wrong.
comment created time in 15 days
pull request commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
@nagisa, pardon, this will need one more r+, as I had to tidy up the style per the failed build. 🙂
comment created time in 15 days
pull request commentmozilla/sccache
Add support for key prefixes when using S3 as the storage
This looks reasonable, but please fix up the formatting errors in the Travis logs.
Done! 🙂
comment created time in 15 days
push eventjakubadamw/rutenspitz
commit sha 40cf9660493e3e96e63a7d3da296665d59f8bef6
One more sentence in the README
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 3ecb59357b57be3ada502ae1c3cb11757870afab
Fix the link
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 05d2870085c3a85a1cb50f287501b9ed0db6fad4
Add a section on operation traces
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 5f29318ff7a8db5834252c4cd4cc300e9f1450cb
Fix links in READMEs.
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 230d03f34016d742d032d64ea633947162a5ba82
Clippy.
push time in 15 days
push eventjakubadamw/sccache
commit sha 253f2c394f8b4481f168021df1d93de9a72c970e
Fix up style
push time in 15 days
created tagjakubadamw/rutenspitz
А procedural macro to be used for testing/fuzzing stateful models against a semantically equivalent but obviously correct implementation
created time in 15 days
created tagjakubadamw/rutenspitz
А procedural macro to be used for testing/fuzzing stateful models against a semantically equivalent but obviously correct implementation
created time in 15 days
push eventjakubadamw/rutenspitz
commit sha 6ce71346d3e67de221a67d0104e852e98b5cf150
0.1.2
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha a52e25d5998cd56b2739d9d0637281903239d08e
Update the licenses.
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 1f4d918ac6d20e7d50730bab5b1b6ee08f6560ed
0.1.1
commit sha 6ccc7e6fca076498f432ad2c4ba79919cce0978f
Get the READMEs in sync.
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha dcdbc882192a583c64dc899058fdce079d99d316
Address Clippy issues.
commit sha 76a04a8c0b755a715964b65cf7050c18832179e2
Update the workflow.
push time in 15 days
push eventjakubadamw/rust
commit sha f5e5eb6f46ef2cf0dd45dba4f975305509334fc6
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha d6151465e7c6f45b2ac5fddd039df9cd11149655
Update the dependencies
commit sha 5e962608eee0c565b8baea72fe44c4d8b153c03f
Update the README.
push time in 15 days
push eventjakubadamw/rutenspitz
commit sha 5c74f20da6cedc4975596f2121087710b824771b
Rename the crate
commit sha 9d8d9ae245705217bcb9f7e06c06ccc920e90d7e
Update the dependencies
push time in 15 days
issue closedjakubadamw/rutenspitz
This crate certainly needs a neater name.
closed time in 15 days
jakubadamw
issue openedjakubadamw/arbitrary-model-tests
This crate certainly needs a neater name.
created time in 15 days
push eventjakubadamw/rust
commit sha 77a2fbb86e9a0cddc18722390d939e9bcd874c64
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
push time in 15 days
pull request commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
@nagisa, okay, I brought back the initial version. 🙂
comment created time in 15 days
push eventjakubadamw/rust
push time in 15 days
Pull request review commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
impl<'a, 'hir> LoweringContext<'a, 'hir> { Applicability::MaybeIncorrect, ) .emit();- break;
@nagisa, thanks! I had the same idea, but in this very case that wouldn't help, because we're already past name resolution.
comment created time in 15 days
pull request commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
@nagisa, thank you. Looks like I stepped on your toes by pushing after your r+, sorry! 🙂 Yeah, I agree the first solution gives nicer results (although implementation wise it's not as simple as the second one). Should we await input from @rust-lang/wg-diagnostics or go ahead with the first approach? If the latter, then I can take back the redundant commits.
comment created time in 15 days
push eventjakubadamw/rust
commit sha cb9ecb459fda73b4d17026cc0d855b2fb08fb21f
Update the test cases with the new diagnostics.
push time in 15 days
push eventjakubadamw/rust
commit sha 070dfbb4164dcbe030ffa386f5c550c696e13d6c
Simplify the fix
push time in 15 days
pull request commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
@JohnTitor, right! So I actually tried an alternate approach that would amount to removing the break and the rest assignment from that case:
PatKind::Ident(ref _bm, ident, Some(ref sub)) if sub.is_rest() => {
- rest = Some((idx, pat.span));
let sp = pat.span;
self.diagnostic()
.struct_span_err(
@@ -128,7 +127,6 @@ impl<'a, 'hir> LoweringContext<'a, 'hir> {
Applicability::MaybeIncorrect,
)
.emit();
- break;
}
But this leads to diagnostics that are, in my opinion, degraded compared to the status quo.
error: `x @` is not allowed in a tuple struct
--> $DIR/issue-74539.rs:9:13
|
LL | x @ ..
| ^^^^^^ this is only allowed in slice patterns
|
= help: remove this and bind each tuple field independently
help: if you don't need to use the contents of x, discard the tuple's remaining fields
|
LL | ..
| ^^
error: `..` patterns are not allowed here
--> $DIR/issue-74539.rs:9:17
|
LL | x @ ..
| ^^
|
= note: only allowed in tuple, tuple struct, and slice patterns
error[E0023]: this pattern has 1 field, but the corresponding tuple variant has 2 fields
--> $DIR/issue-74539.rs:8:9
|
LL | A(u8, u8),
| --------- tuple variant defined here
...
LL | / E::A(
LL | | x @ ..
LL | | ) => { x }
| |_________^ expected 2 fields, found 1
error: aborting due to 3 previous errors
For more information about this error, try `rustc --explain E0023`.
We end up with two extra diagnostics which are not very useful.
comment created time in 15 days
Pull request review commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
+enum E {+ A(u8, u8),+}++fn main() {+ let e = E::A(2, 3);+ match e {+ E::A(x @ ..) => { //~ ERROR `x @` is not allowed in a tuple+ x //~ ERROR cannot find value `x` in this scope
@JohnTitor, this is a consequence of the nature of the fix. But I think you're right, this should be done differently.
comment created time in 15 days
issue commentrust-lang/rust
ICE with the `@ ..` binding pattern
@JohnTitor, okay, thanks. 🙂
Better late than never…
@rustbot claim
comment created time in 15 days
pull request commentrust-lang/rust
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
@JohnTitor, oh, I see in https://github.com/rust-lang/rust/issues/74539#issuecomment-661031765 that you had another solution in mind? :)
@jakubadamw Great! You should tweak
src/librustc_ast_lowering/pat.rsnot losing diags. For further reference, you could do@rustbot claimwhen you work on an issue to avoid conflicts.
What do you mean by “not losing diags”? The thing is that AST lowering runs after name resolution. How else could it “poison” that particular invalid binding? Sorry, I don't know the compiler very well, it's been years since. 🙂
comment created time in 15 days
push eventjakubadamw/rust
commit sha 249e07b237bd3049eb7fd94afe450b7c09b6a3d9
Short documentation for the false keyword
commit sha ba6857d801b6217a190e92e43cacd8468ff2d72a
Document the trait keyword
commit sha 18be370342c9b2a93f1d56b2b674bd2fbdcbb019
Add core::ready! macro
commit sha c38230e3b639783483277465ff3c3436a8fd5545
Deny unsafe op in unsafe functions in libstd/alloc.rs
commit sha afbfe603fc1c288a0cff63b3b1cad43902a66e9b
Remove combine function Comparing two array directly helps generate better assert message
commit sha 75748a4116c1d3bbdedd9d2f9c1cf95d9f4d9df7
ci: Update dist-{i686,x86_64}-linux to Debian 6 This increases the minimum `{i686,x86_64}-unknown-linux-gnu` platform from RHEL/CentOS 5 (glibc 2.5 and kernel 2.6.18) to a slightly newer Debian 6 `squeeze` (glibc 2.11 and kernel 2.6.32). While that release is already EOL, it happens to match the minimum common versions of two enterprise distros that do still need Rust support -- RHEL 6 (glibc 2.12 and kernel 2.6.32) and SLES 11 SP4 (glibc 2.11 and kernel 3.0).
commit sha 48ec236c8c7c5a32077c465eb254646a9860f802
start GBA file.
commit sha cac1768b03c8d6673c51605dca03997876979d68
First cut of `std::lazy` module
commit sha 237a97760ad79a21ce0655b9f5adc0cc5b5cbc79
integrate Lazy into std layout This commit refactors the initial implementation to fit into std and makes some other changes: - use MaybeUninit internally in SyncOnceCell - correctly impl Drop for lazy::Once - port Lazy::take from once_cell from: https://github.com/matklad/once_cell/pull/100 Co-Authored-By: Paul Dicker <pitdicker@users.noreply.github.com>
commit sha d1263f5e66d31ad170c524a70aa5f21e08474326
use set() in SyncOnceCell::from
commit sha d1017940d77f35f841008c3e108e3da5e48a592f
remove inlined lazy::Waiter in favor of sync::Once
commit sha 1f1cda65d9a5c88855d3fbcb3912095474e557de
appease tidy
commit sha 8a2f147b5b9756e67dc2299777b8b534bbd73d0b
Fix small nits, clarfying some confusing vocabulary and using more consistent wording
commit sha e190bdf710101d8fdf12195dcc73749719a57e72
fill in all those options.
commit sha ab23a2a9c54fed2acbd553407a761f19af6e8ed4
ci: Set `shell: bash` as a default, remove duplicates A follow-up to #74406, this commit merely removes the `shell: bash` lines where they are explicitly added in favor of setting defaults for *all* "run" steps. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
commit sha 9c4ac7395953435a5f39cfaf93c7679df068bade
Docs clarifications.
commit sha 72fa7f82503d4eb3c09e5dce600ac044c2835688
Add to supported_targets list.
commit sha 66a3d6859ba8cca6eab614014c001a0ef4be9809
fix the imports.
commit sha b26ecd261b827837df8bb01c8fd5bf80dced8909
Test codegen of compare_exchange operations
commit sha 7cbff846edcedc7ab9d0dfd82e6f711fe99e2520
Resolve https://github.com/rust-lang/rust/pull/74419#discussion_r456141344
push time in 15 days
push eventjakubadamw/rust
commit sha db77a9e516ad37a730c19e3c008c7279b5767aa7
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
push time in 15 days
push eventjakubadamw/rust
commit sha fb9ef4cc77476d04de09d204d731b1f0305775d2
Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern
push time in 15 days
issue commentrust-lang/rust
ICE with the `@ ..` binding pattern
@JohnTitor, oh, sorry, I've already got a fix. 🙂 I'll post it soon. Though it may not be the best one.
comment created time in 15 days
issue commentrust-lang/rust
Binary search ought to be the most overstudied algorithm in computer science. It's important to keep that in mind when one sees a new revelation about it on Hacker News.
If one is interested in experimenting with the different n-ary search algorithms in Rust in a crate, that sounds like an idea, but it seems out of scope for the standard library. All the more that the quaternary variant, where they report a “25%” speed-up in their tests and data set, is not even a binary search (though for some reason they call it a “quaternary binary search”, which is funny).
comment created time in 15 days
push eventjakubadamw/youtube-dl
commit sha db6364df21e02ac7f400a25a7aef8e4dd0824c5d
[polskieradio] Fix extraction for the updated article page theme
commit sha 88d220db23c32ef16aa52ad15210b31455cff944
[polskieradio] Change the test case for playlist extraction The previous one has for some reason been removed from the Web site.
commit sha a75e8add8aecdf8a66bd7d125a11ffabe8a66e8b
[polskieradio] Add a test for new-style multiple broadcast playlists.
push time in 16 days
PR opened ytdl-org/youtube-dl
Before submitting a pull request make sure you have:
- [x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
- [x] Searched the bugtracker for similar pull requests
- [x] Checked the code with flake8
In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:
- [x] I am the original author of this code and I am willing to release it under Unlicense
- [ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)
What is the purpose of your pull request?
- [x] Bug fix
- [x] Improvement
- [ ] New extractor
- [ ] New feature
Description of your pull request and other information
This PR is an update to the Polskie Radio (Polish Radio) extractor. Recently, the Polish national broadcaster has slightly updated the HTML for new broadcast pages, and the extractor as-is could not handle it.
Examples
Updated style: https://www.polskieradio.pl/8/2382/Artykul/2534482,Zagarysci-Poezja-jak-spoiwo
Old style: https://www.polskieradio.pl/8/2382/Artykul/1500172,Mistrz-i-Malgorzata-Bulhakow-w-krwiobiegu-kultury
Additionally, I've changed one test case as it referred to a broadcast that for some reason had been removed, and added one more for new-style multiple broadcast playlists.
pr created time in 16 days
push eventjakubadamw/youtube-dl
commit sha d4375765bf68864800ad974decf6fafde8a3d0a0
[polskieradio] Add a test for new-style multiple broadcast playlists.
push time in 16 days
push eventjakubadamw/youtube-dl
commit sha 3a3129ebf8760be104ff0640e3ee0ca73d65ada9
[polskieradio] Fix extraction for the updated article page theme
commit sha 075889b28e3824f9e84acde0dfb3e8390e68d284
[polskieradio] Change the test case for playlist extraction The previous one has for some reason been removed from the Web site.
push time in 16 days
push eventjakubadamw/youtube-dl
commit sha 616a39185df49edc891c7ea2331a59c5fc19edb6
[polskieradio] Add a test for new-style multiple broadcast playlists.
push time in 16 days