profile
viewpoint

Manishearth/rust-tenacious 36

Lint to disallow the moving of marked types in Rust

nox/arbalest 21

Like Arc<T> but where weak references don't forbid mutable access

nox/coopted_llvm 10

Coöpt rustc‘s own LLVM to do fancy stuff with it

nox/cargo-old-lock 4

Print a Cargo manifest, old style

nox/apple-libc 2

A mirror of Apple's libc

nox/cowboy 2

Small, fast, modular HTTP server.

mbrubeck/servo 1

The Servo Browser Engine

nox/atomic_refcell 0

Threadsafe RefCell for Rust

issue commentrust-lang/compiler-builtins

figure out some mechanism to alias symbols

Another interesting thing is being able to replace a symbol by a different one if a third symbol is used in the final program, and I have no idea how we would model that in Rust. To take an example, AFAIU there is 2 translation units in musl to support syscalls that are cancellation points, the first one defines __syscall_cp_c as a weak alias to sccp, which is just a dumb wrapper around __syscall, and the second one actually defines __syscall_cp_c as a function that can handle thread cancellation during syscalls properly. That latter definition is used only if the translation unit that contains it is used in the final program, that is if pthread_cancel is actually used.

Or is my understanding of this stuff completely wrong?

If I'm correct, how would do this dance in Rust?

japaric

comment created time in 8 days

issue commentrust-lang/rust

Provide suggestion on E0277 Sized error when `&**`/`as_ref()` would be appropriate

Though @yaahc just informed me that we can't because there is an impl of From<E> where E: Error for Box<dyn Error>. Oh well.

estebank

comment created time in 15 days

issue commentrust-lang/rust

Provide suggestion on E0277 Sized error when `&**`/`as_ref()` would be appropriate

This happens because this impl exists:

impl<T> Error for Box<T> where T: Error { … }

Relaxing the implicit Sized bound in this impl makes the error go away entirely.

estebank

comment created time in 15 days

pull request commentrust-lang/rust

WIP: Add RawVec to unify raw Vecish code

This probably doesn't matter in real life, but I just realised this PR regressed Cow::deref because prior to this PR, both variants of Cow<str> had (ptr, len) in that order, meaning Cow::deref just returned that pair in both paths.

Gankra

comment created time in 20 days

issue commentupsuper/cstr

Consider removing the syn dependency

Note, I opened an issue, but I'm not asking you to do such a task, if you would consider copy-pasting the code, don't do it yourself! I can do that on my own no problems, I have a lot of free time these days.

nox

comment created time in a month

issue commentupsuper/cstr

Consider removing the syn dependency

I'm interested in why you would like to remove syn? It's such a common crate that basically every proc macro depends on, and you end up depending on it in every project with reasonable number of dependencies.

Because most large projects use syn, but many crates where I would use a cstr crate don't.

For example, most crates binding to third-party code don't need syn.

nox

comment created time in a month

issue commentrust-lang/rust

io::Stderr should be line-buffered by default, not unbuffered

stderr in C is supposed to be unbuffered too AFAIK.

zackw

comment created time in a month

issue commentupsuper/cstr

Consider removing the syn dependency

I seriously don't see the problem: Rust string literals aren't going to change any time soon, there is nothing to maintain here, just code to copy and paste and never touch again.

nox

comment created time in a month

issue openedupsuper/cstr

Consider removing the syn dependency

The only thing needing is the function to parse a string literal, do we really need to bring in all of syn for that? Would you consider merging a PR that duplicates syn's own function to parse a string?

created time in a month

issue commentnox/serde_urlencoded

Support sequence-like values in a key-value map

You may want to use serde_qs rather than that crate btw.

rubdos

comment created time in a month

issue closednox/serde_urlencoded

Support sequence-like values in a key-value map

Consider

#[derive(Serialize)]
struct Foo {
    field: Vec<String>,
}

or

let foo = [
    "key", vec!["hello", "world"],
]

or the HashMap-equivalent of the above. These all currently throw "unsupported value" errors. It would be extremely nice to have this supported, and serialized into key[0]=hello&key[1]=world.

closed time in a month

rubdos

issue commentnox/serde_urlencoded

Support sequence-like values in a key-value map

Your foo example does not type check, but apart from that such use cases are explicitly out of scope, sorry.

rubdos

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Invoking methods upon extern types sounds messy.

How so? It's just a type that is not sized, but otherwise is just the same as any other type. It's not weirder than having methods on dyn Any or usize.

nox

comment created time in a month

create barnchnox/apple-libc

branch : master

created branch time in a month

created repositorynox/apple-libc

A mirror of Apple's libc

created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Returning 0 would be a-ok I think and I didn't know it was the current default, I guess I should have tried it at some point. Then all the rest that I mentioned to later introduce an opt-out DynSized gets downgraded to a simple "nice to have" thing in my book.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

We talked about this in the lang team meeting on Monday. We still had consensus within the team that we think adding new ?Traits to the language is a very invasive change, and we do not think making size_of_val/align_of_val compile fail for extern types justifies adding one.

I disagree and I think it would be a quite a wart to land extern types that can trivially make the program abort just passing them to size_of_val. The other aborting thing I can remember existing in Rust is refcount overflows, and that is quite more difficult to make happen by accident. That being said, I'm not in the language team, and I already stated all of that, so I'm not sure why I'm repeating it again anyway. The ship sailed and I'm ok with that.

However, we do think the area these RFCs are in is within our roadmap, and we'd be supportive of movement to make FFI and unsafe code involving dynamically sized types easier and less error prone to work with. We thought that work on extern types (with the panic-based solution) and #2580 would be obvious next steps. One path toward getting this done would be for the MCP group currently working on safe transmute to focus on dynamically sized types after the current round of safe transmute RFCs are done. This group seems well suited to working on FFI/unsafe code issues around layout and representation.

I don't think I would use extern types that may make my program abort if someone uses them in an unexpected way, I'll probably stick to zero-sized empty structures.

These were the backward compatibility problems I alluded to in earlier post. :\ They hampered any attempt to add ?Move in a similar way, though there it emerged from Fn trait outputs.

I see! I'll try (my prose sucks when there is a dozen of independent details to talk about at once) to mention them explicitly in this RFC, as even @eddyb had completely forgot about the issues with associated types hah. At this point I just want a papertrail for next time someone else wants to have unsized types again. 😅

<hr>

That being said, if we ever want to revisit whether or not to add an additional opt-out language trait, I think we could anyway through a Rust edition: we could pretend that Rust 2018 extern types implement, say, the Contiguous trait from the custom DST RFC with aborting methods, while extern types in the next edition just don't implement that trait. Coupled with a system that implies the Contiguous trait bound everywhere in Rust 2018 and doesn't in the new edition, this would mean we could introduce truly unsized types later even if we land custom DSTs or extern types now.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

I need to amend this RFC to expand it based on the implementation work I did these last days.

The TL;DR is that it is extremely not trivial to add any new opt-out bound to the language, because associated types don't imply any trait bounds currently.

To make &ExternType useful, you need to make it implement Deref, but Deref as it is cannot be implemented with !DynSized Self or Self::Target types. If we relax the DynSized trait bounds on them, we break third-party code because now code relying on the Deref trait cannot assume anymore that the values are DynSized.

https://twitter.com/nokusu/status/1305553609598406656

One way to fix the problem would be to make T or <T as Foo>::Bar always imply DynSized unless it's explicitly ?DynSized, but that's a pretty big change and may have performance problems.

<hr>

Note that I agree that this kind of shenanigans would be hard to teach, but I feel like maybe this stuff could bake in nightly for a long period with extern types and see where it goes. There are other Rust features that were considered hard to teach that were reconsidered after baking for a while after all.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

@retep998 The intent with this tiny (in scope but not impact) RFC was that extern types can then be defined as !DynSized, and then the custom DST RFC can take care of letting users implement DynSized themselves for such use cases. You only mentioned alignment, but there is a size in there too, for the allocated memory, right?

nox

comment created time in a month

pull request commenterlang/otp

Implement BeamAsm - a JIT for Erlang/OTP

Yep, it was one of our design goals. Changing to a different assembler is pretty straightforward and going down the IR route shouldn't be too difficult either, albeit tedious as you need to re-implement every instruction.

Super cool to know! And I'm super happy to see progress in that part of the Erlang VM. Now if only Ericsson was hiring remote… 😎

garazdawi

comment created time in a month

pull request commenterlang/otp

Implement BeamAsm - a JIT for Erlang/OTP

Sorry for the side-tracking, as I could look into that myself, but I have a small question: is the implementation modular, done in a way where we could later experiment with different JIT backends, such as Rust's cranelift?

garazdawi

comment created time in a month

pull request commentrust-lang/rust

Some cleanup changes and commenting

I added a comment on is_trivially_sized. This PR does pretty much nothing now, so you may just want to close it and spare the CI cycles.

nox

comment created time in a month

push eventnox/rust

Anthony Ramine

commit sha 4f0047ed108889ea97ad7656307a8a829dd56636

Add a comment on is_trivially_sized about obviously !Sized types

view details

Anthony Ramine

commit sha 75f0f7af3172cedaa01e9bf066c06017bfe9a426

Fix a typo

view details

Anthony Ramine

commit sha caf6c92d19216d75bf248643a11df77a598293e7

Clean up some language trait items comparisons

view details

push time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

If I understand @nox remarks, there do not exist acceptable trait constraint solutions for core::mem::*_of_val* because many existing traits break either way , so core::mem::*_of_val* must panic for extern types.

Yeah more or less. I think implementing trait Foo: ?DynSized could maybe work, with crater runs afterwards to check that something like trait Debug: ?DynSized doesn't break the entire crater world, but that's still the good old "that's a breaking change but crater didn't complain so YOLO", and I'm not going to argue very strongly in favour of such a thing.

nox

comment created time in a month

Pull request review commentrust-lang/rust

Improve the fast path of `is_sized` and drive-by improve a few things

 impl<'tcx> TyS<'tcx> {             | ty::Array(..)             | ty::Closure(..)             | ty::Never-            | ty::Error(_) => true,+            | ty::Error(_) => Some(true), -            ty::Str | ty::Slice(_) | ty::Dynamic(..) | ty::Foreign(..) => false,+            ty::Str | ty::Slice(_) | ty::Dynamic(..) | ty::Foreign(..) => Some(false), -            ty::Tuple(tys) => tys.iter().all(|ty| ty.expect_ty().is_trivially_sized(tcx)),+            ty::Tuple(tys) => {+                for ty in tys.iter() {+                    if !ty.expect_ty().is_trivially_sized(tcx)? {+                        return Some(false);+                    }+                }+                Some(true)+            } -            ty::Adt(def, _substs) => def.sized_constraint(tcx).is_empty(),+            ty::Adt(def, _substs) => {+                if def.sized_constraint(tcx).is_empty() {+                    Some(true)+                } else {+                    None+                }+            }

Thanks, I didn't know about that method.

nox

comment created time in a month

PullRequestReviewEvent

pull request commentrust-lang/rust

Improve the fast path of `is_sized` and drive-by improve a few things

I'll change that commit to be adding a comment explaining why we can't fast-path types that are trivially !Sized.

nox

comment created time in a month

pull request commentrust-lang/rust

Improve the fast path of `is_sized` and drive-by improve a few things

@eddyb

Seems like we forgot about nonsensical bounds in nonsensical code.


---- [ui] ui/trivial-bounds/trivial-bounds-inconsistent-well-formed.rs stdout ----

error: test compilation failed although it shouldn't!
status: exit code: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/trivial-bounds/trivial-bounds-inconsistent-well-formed.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/trivial-bounds/trivial-bounds-inconsistent-well-formed/a" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/trivial-bounds/trivial-bounds-inconsistent-well-formed/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error[E0161]: cannot move a value of type str: the size of str cannot be statically determined
  --> /checkout/src/test/ui/trivial-bounds/trivial-bounds-inconsistent-well-formed.rs:10:18
   |
LL |     let x = vec![*"1"];
   |                  ^^^^

error: aborting due to previous error

That test does str: Copy hah.

nox

comment created time in a month

push eventnox/rust

Anthony Ramine

commit sha 413741523a6aac19c551681284efbdbe62d39f93

Improve the fast path for trivial Sized decision There is no need to go through the slow path if we are sure it's !Sized.

view details

Anthony Ramine

commit sha 7d46bb9de14b01af0c263d633f8463dc93ab2a74

Fix a typo

view details

Anthony Ramine

commit sha ff5c5a6eff4dfbf865c045e510c83c17c00a5e82

Clean up some language trait items comparisons

view details

push time in a month

PR opened rust-lang/rust

Improve the fast path of `is_sized` and drive-by improve a few things

r? @nikomatsakis Cc @eddyb

+32 -36

0 comment

6 changed files

pr created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Why not just have size_of_val panic on extern types? (and add a maybe_size_of_val that returns an Option instead)

Please read the threads, there are various FFI crate maintainers that are not much in favour of doing that, there are arguments for and against doing that. In general, not doing things "just" because they would be complicated to explain afterwards tend to frustrate people. Note that I'm not saying this is justified, just that it is how I see things from where I stand. This is why I made this RFC: I took the controversial part of introducing something like DynSized and made it its own RFC disconnected from pointer metadata, extern types or custom DST to see what happens.

I also disagree with the idea of "we shouldn't take years to get a consensus on a complex design", especially if it is about landing extern types that can't be used in say, winapi. Extern types are a very old RFC that is still not stabilised and as far I know it's now like there is an extreme urgency to land them.

<hr>

For what it's worth, I'm also playing with an implementation and finding more arguments against it that aren't related to how we teach it. For example, we can't make trait Foo {} not imply Self: ?DynSized because that would be a very invasive breaking change for the entire ecosystem, so instead we would need to do trait Foo: ?DynSized {} to allow a trait to be used with extern types, which means that we now have a ?Trait syntax were none were allowed before.

nox

comment created time in a month

pull request commenterlang/otp

Implement BeamAsm - a JIT for Erlang/OTP

Congratulations, can't believe this is happening! Now RIIR it, jk.

garazdawi

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Yes that’s what the RFC for custom DST suggests more or less, but the goal of this RFC is to specify the parts that support adding custom DSTs later, not define them right now.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

@petertodd I al not sure how that relates to this RFC, whether or not it is decided to adopt something similar to the DynSized trait here, it doesn’t let you implement custom DST so not being to support Box<ExternType> is out of scope, isn’t it? It is not supported either in the current implementation of extern types because size_of_val etc don’t have any sensical value to return.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Good to know! Totally understand for bandwidth, especially with pandemic.

<hr>

But anyway… sorry if I missed this concern in one of the dozen related RFCs and threads, but I just realised something: if we implement what I just proposed, extern types end up not even DynSized, right? And a definition such as trait Foo {} must continue to imply Self: DynSized otherwise existing code using size_of_val starts breaking. So with my scheme, an extern type cannot implement say, Debug, because we can't change trait Debug to mean trait Debug: ?DynSized. So in the end, none of the fancy extern types that I wish to use directly in a neat safe wrapper can even implement some of the most basic traits. Am I correct?

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Wouldn't it be a good idea to be able to replace that bound list itself with another auto trait in the future (e.g. at least leave that as an option/implementation detail)? e.g.

Auto traits cannot have supertraits so I encoded things that way, but that was my first idea too.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Thanks for expanding.

Apart from ?DynSized, is there anything else that feels like a blocker to you? Hear me out: RFCs are sometimes for experimental stuff and have no guarantee to ever be stabilised, right? Let's assume that the code for Pointee/DynSized exist, would it be useful to experiment around the idea in nightly? Maybe with a separate feature that encodes that stuff as positive bounds of the supertrait (e.g. T: DynSized instead of T: ?Sized and T: Pointee instead of T: ?DynSized)? Obviously, someone would need to write that code, and that's a hard task, but in theory, that would be interesting, right?

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

I realize that users who are deeply invested in writing FFI bindings would like their bindings to be as typesafe as possible, and would like the compiler to check that users do not pass extern types to APIs which cannot rationally accept them, but this has to be balanced against the cost to all other users.

Thanks for that.

This cost is twofold: the burden added to writing and maintaining correct Rust libraries, and the burden added to learning Rust.

Are you completely closed to the idea that maybe having more than one opt-out bound would actually help understand how opt-out bounds work?

By adding ?DynSized, every API which uses a ?Sized bound currently needs to review whether it ought to be ?DynSized bound. When I reviewed std in 2018, every API accept Box could have taken ?DynSized, as I recall, because Box needs the layout of the type to call its destructor. Forcing everyone to consider this question would very be disruptive. But the disruption is not one-and-done, because now every new ?Sized bound added in the future needs to decide whether it can take extern types or not.

I don't see this as an argument against DynSized at all: it boils down to crates that predate extern types may not support extern types where they could, but how is that a problem given extern types didn't exist when these crates were created?

To me that's like arguing against no_std because some crates could have been no_std before no_std was a thing.

Similarly, the ?Sized feature is very confusing to new users, and I think ?DynSized would compound that. Adding ?Sized would mean "my type is maybe a DST" whereas adding ?DynSized would mean "my type is maybe an extern type. This is not intuitive if you don't already understand the whole system. Error messages about Sized would in some cases probably now say DynSized, complecting the existing issues they present to users. Not understanding how Sized works has been the biggest user confusion with the trait system in my experience.

Fair, I personally don't think 1 or 2 of those change the complexity of the system but that's a matter of opinion anyway.

I just don't think compile time checking that no one tries to get the layout of an extern type is valuable enough to justify these burdens.

Also fair, but I really feel like DynSized strengthen all those RFCs about pointer metadata, extern types and potential custom dynamically sized types all at once, which sounds great to me. Things that look like a solid foundation for multiple concepts at once are good in general.

The syntax to define the Meta type could be special, impl !Sized for MyType, maybe, for example, or we could indeed use a trait like Pointee. The point is not to introduce this additional burdens I described above.

To me, that seems like way more of a burden than ?Sized/?DinSized on the education front. "Yeah so you are opting-out from a trait (Sized), but at the same time you bound on something like an associated type to the supertrait of Sized". See what I mean?

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

If there is no such additional ?Trait at all, doesn't that set in stone that there will never be any custom dynamically sized types? How do you retrofit a trait to define dynamically sized types under Sized once extern types with an adhoc lint or ?Sized<Meta = …> are shipped?

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

From my own perspective, there are quite a few community actors that maintain FFI crates that want something like DynSized, and a majority of language team members that are strongly against it, hence my conclusion that the whole process is blocked, because it looked like ultimately no one wanted to make the jump and take a final decision. My reading seems to be wrong about this, but I nonetheless agree with the people who want proper type support rather than runtime aborts and ad-hoc lints.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

@withoutboats Could you expand on why you are ok with Pointee but not DynSized to reject size_of_val from being rejected with extern types? Is it just because of the additional opt-out bound?

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Cc @retep998 who makes winapi and who also expressed interest for a proper support of unsized types at the type-level.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Apologies for the derail. I'm asking if &T should make sense when T is an extern type.

Oh I see. My own use case for extern types is to improve bindings for things such as the Carbon APIs on macOS, which are all defined as typedef struct __CFFoo CFFoo; on the C side. Being able to represent that as extern { type CFFoo; } on the Rust side makes the safe wrappers as thin (no pun intended) as they could be with no need to unwrap or rewrap things constantly in the code.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

I doubt this works but.. Is there any value in distinguishing between raw pointers and borrowed references here? In other words, could &T simply not exist whenever size_of_val::<T> makes no sense? We'd still have *const T though so we'd then need roughly #1403 so that *const T could be wrapped into some reference type for safe borrowing.

I don't understand why that would be useful, extern types definitely let you get a &T but size_of_val makes no sense for them.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

I'll amend the RFC to include more unresolved questions based on this discussion. I don't care if the PR ends up closed, I just feel like it would be a good thing to have a document that centralise them anyway.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

This isn't the case. People suggest additional question mark types with regularity. Some people want to revisit Move, some people want a ?Trait to add linear types, its even been proposed (though I think only offline) to add a ?Trait governing whether a type exists in 1 memory space or more, to better support wasm reference types. I think all of these would be a poor choice, for many of the same reasons as ?DynSized.

Ack, I meant that I don't see people from any Rust team pushing for those, but maybe I'm just not seeing those discussions.

People want to use the ?Trait feature to add new exceptions to the requirements that Rust currently assumes every type adheres to. I don't think we should ever do this, because going from one ?Trait to more than one is, in my opinion, remarkably expensive in terms of onboarding new users and headaches for existing users, concerns you mention but dismiss.

I didn't dismiss anything, I literally started my comment by saying that I probably missed some concerns. Given there was never more than one ?Trait thing, how can we conclude that more than one would be more painful? Some people argued in the other threads than having more than one would actually help because it would make it less of a special case. None of the two hypotheses have been tested because there was never more than one opt-out bound.

This isn't why we haven't made progress on extern types. We haven't made progress because no one is driving the feature. I think within the lang team there is (weak) consensus that making size_of_val/align_of_val panic when passed an extern type would be an adequate solution, and I don't think the feature is blocked on having a compile-time solution.

Ack. I shouldn't have mentioned size_of_val specifically but from an external point of view, it feels like no one is driving the feature because the gist of it interacts with half a dozen RFC which all have their own individual concerns without really seeing how it fits with the others, hence that RFC. As for having a compile-time solution for size_of_val, I was biaised by the fact that I need a compile-time solution for "accept all thin pointers whether sized or not", which then gives us a way to compile-time reject non-sensical size_of_val uses for free.

nox

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

I probably missed a lot of small concerns, but here is a first stream of thought with some direct pointers to past comments.

<hr>

So the first concern mentioned in #2255 is that opt-out bounds such as ?Sized are confusing to users, so adding ?DynSized would add confusion. This concern was first raised by @withoutboats in https://github.com/rust-lang/rust/pull/46108#issuecomment-353217027 back in December 2017. In January 2018, @arielb1 argued in https://github.com/rust-lang/rfcs/issues/2255#issuecomment-360985959 that this may not be as much as a problem as initially thought because it makes sense given the hierarchical relation Sized: DynSized.

My own framing on that is that going from T to T: ?Sized to T: DynSized is like peeling an onion, removing a layer of implicit bounds with each increasingly bigger opt-out bound.

@mikeyhew then adds in https://github.com/rust-lang/rfcs/issues/2255#issuecomment-361040229 that they would rather allow the user to write normal bounds of supertraits of Sized and make the compiler remove implicit bounds of the corresponding subtraits. I.e. writing T: Pointee would imply T: ?DynSized, and T: DynSized would imply T: ?Sized. @withoutboats later partially agrees to that in https://github.com/rust-lang/rfcs/issues/2255#issuecomment-361049935.

I agree with @mikeyhew that this is something that could be done, but my understanding is that it is mechanically equivalent to allowing T: ?DynSized and thus could be a major change introduced in a later Rust edition where we would allow code using T: ?Sized (or T: ?DynSized) to be rewritten to T: DynSized (or T: Pointee).

In April 2018, @nikomatsakis writes in https://github.com/rust-lang/rust/issues/43467#issuecomment-379069914 that he doesn't think that T: ?Sized should imply T: DynSized and instead there should just be lints or runtime checks against using size_of_val with a !DynSized type, and that this kind of concern around size_of_val should not block extern types from landing.

In my opinion, extern types still didn't land exactly because we still don't have a DynSized concept to prevent extern types from being used with size_of_val, because it makes things very vaguely defined and this doesn't motivate anyone from pushing extern types to completion.

Finally in September 2019, @Ixrec in https://github.com/rust-lang/rfcs/issues/2255#issuecomment-526869021 follows-up that ?Move has been abandoned and absolutely nobody else ever suggested a different opt-out trait with a ?Trait syntax.

In my opinion, we can confidently say that an additional ?DynSized thing wouldn't confuse users more than ?Sized may have confused them.

<hr>

The second concern is raised by @eddyb in https://github.com/rust-lang/rfcs/issues/2255#issuecomment-361052894 and is about whether we should plan for !Pointee types later down the road. If so, should T: Pointee be implied all the time, meaning that !Pointee types are then only allowed in T: ?Pointee code? @eddyb later in https://github.com/rust-lang/rfcs/issues/2255#issuecomment-361084228 suggests that !Pointee types could instead be encoded as Pointee<Meta = !>.

<hr>

@kennytm in #2255 also mentions that introducing ?DynSized means downstream crates will have to reconsider all their ?Sized bounds to check if they could benefit from being ?DynSized.

I don't think extending the language to support some kinds of non-dynamically-sized types should be blocked on downstream crates not supporting them from the get-go.

<hr>

To conclude, reading through the comments of #2255 reaffirms my belief that this RFC defines the most viable core that we should go for as a first step for extern types and pointer metadata APIs, given that the gist of the concerns from the language team is the ergonomic cost of ?DynSized and we can always revisit that in a later language edition where we would make T: DynSized imply T: ?Sized as opposed to T: ?Sized implying T: DynSized.

nox

comment created time in a month

issue commentnox/serde_urlencoded

Please publish a new version

It would be nice if there were a CHANGELOG in the repo.

Patches welcome.

This crate is being used by many other major stable crates, such as actix-web, and is thus being used in production by a lot of people. Would you consider switching to 1.x and guarantee backward compatibility ?

No.

jplatte

comment created time in a month

pull request commentrust-lang/rfcs

Introduce Pointee and DynSized

Thanks for the pointer, I missed this one and will now look into it.

nox

comment created time in a month

PR opened rust-lang/rfcs

Introduce Pointee and DynSized

Those two new language traits are at the intersection of #1861, #2580, #2594, and this RFC's raison d'être is solely to try to get some progress for those 3 RFCs all at once by specifying their common core part.

+160 -0

0 comment

1 changed file

pr created time in a month

push eventnox/rust-rfcs

Anthony Ramine

commit sha fc3481c7db1598a96443b714481f65e339cc2d4e

Introduce Pointee and DynSized Those two new language traits are at the intersection of #1861, #2580, #2594, and this RFC's raison d'être is solely to try to get some progress for those 3 RFCs all at once by specifying their common core part.

view details

push time in a month

issue closednox/serde_urlencoded

Please publish a new version

In particular because of #74, #79.

closed time in a month

jplatte

delete branch nox/serde_urlencoded

delete branch : seven

delete time in a month

pull request commentnox/serde_urlencoded

Release 0.7.0 version

bors r+

nox

comment created time in a month

PR opened nox/serde_urlencoded

Release 0.7.0 version
+11 -8

0 comment

2 changed files

pr created time in a month

push eventnox/serde_urlencoded

Anthony Ramine

commit sha 64dcc66a28bcd83afc6dff80bcb6feae23f48548

Release 0.7.0 version (fixes #47, #83)

view details

push time in a month

PR closed nox/serde_urlencoded

2018 edition

This was generated with cargo fix --edition so should resolve the comments on #56

+12 -12

7 comments

6 changed files

Gisleburt

pr closed time in a month

create barnchnox/serde_urlencoded

branch : seven

created branch time in a month

issue closednox/serde_urlencoded

Write crate-level documentation and usage examples

https://docs.rs/serde_urlencoded/0.5.3/serde_urlencoded/ needs a more helpful landing page.

closed time in a month

dtolnay

issue commentnox/serde_urlencoded

Write crate-level documentation and usage examples

Closing for lack of a PR.

dtolnay

comment created time in a month

issue commentnox/serde_urlencoded

Please publish a new version

Doing this now.

jplatte

comment created time in a month

issue commentnox/serde_urlencoded

Example for chrono::NaiveDateTime in qs

Note that I didn't forget about that but I got laid off so I'm just a bit distracted. :D

thiskevinwang

comment created time in 2 months

issue commentservo/servo

A long term / sustainable plan proposal for servo and firefox

You're free to do so on your own, I'm locking this issue.

LifeIsStrange

comment created time in 2 months

issue commentnox/serde_urlencoded

Example for chrono::NaiveDateTime in qs

Interesting, will look into that, I guess I have quite some free time right now hah.

thiskevinwang

comment created time in 2 months

issue commentnox/serde_urlencoded

Example for chrono::NaiveDateTime in qs

Did you check what [("foo", some_naive_date_time)] encode to? Does it work? Does it then fail to roundtrip?

thiskevinwang

comment created time in 2 months

pull request commentnox/serde_urlencoded

Format code using 'cargo fmt' & add formatting check on CI

bors r+

Atul9

comment created time in 2 months

Pull request review commentnox/serde_urlencoded

Format code using 'cargo fmt' & add formatting check on CI

-match_block_trailing_comma = true+match_block_trailing_comma = false

Thanks for the explanation.

Atul9

comment created time in 2 months

Pull request review commentnox/serde_urlencoded

Format code using 'cargo fmt' & add formatting check on CI

-match_block_trailing_comma = true+match_block_trailing_comma = false

Why did you change this?

Atul9

comment created time in 2 months

pull request commentnox/serde_urlencoded

Update to edition 2018 & clippy

bors r+

Thanks again!

nickelc

comment created time in 2 months

Pull request review commentnox/serde_urlencoded

Update to edition 2018 & clippy

 pub fn to_string<T: ser::Serialize>(input: T) -> Result<String, Error> { ///   unit structs and unit variants. /// /// * Newtype structs defer to their inner values.-pub struct Serializer<'input, 'output, Target: 'output + UrlEncodedTarget> {+pub struct Serializer<'input, 'output, Target: UrlEncodedTarget> {

Nice catch.

nickelc

comment created time in 2 months

PullRequestEvent

pull request commentnox/serde_urlencoded

Format code using 'cargo fmt'

Sure.

Atul9

comment created time in 2 months

pull request commentnox/serde_urlencoded

Update to edition 2018 & clippy

Please remove the commit that removes the Error stuff.

nickelc

comment created time in 2 months

Pull request review commentnox/serde_urlencoded

Update to edition 2018 & clippy

-extern crate serde_urlencoded;+use serde_urlencoded;

Pretty sure that's unneeded.

nickelc

comment created time in 2 months

pull request commentnox/serde_urlencoded

2018 edition

I'll merge it if it gets rebased.

Gisleburt

comment created time in 2 months

pull request commentnox/serde_urlencoded

Badges for crates.io, docs.rs and build status

Thanks for the contribution but I don't like badges, those images are a waste of bandwidth.

piotrmaks

comment created time in 2 months

PR closed nox/serde_urlencoded

Format code using 'cargo fmt'
+45 -18

2 comments

3 changed files

Atul9

pr closed time in 2 months

pull request commentnox/serde_urlencoded

Format code using 'cargo fmt'

Thanks for the contribution but as Piotr says it has no purpose if it is not automated.

Atul9

comment created time in 2 months

pull request commentnox/serde_urlencoded

Switch from dtoa to ryu

bors r+

nickelc

comment created time in 2 months

PR opened servo/rust-mozjs

Update mozjs_sys to bring the new proxy stuff
+2 -2

0 comment

1 changed file

pr created time in 3 months

push eventservo/rust-mozjs

Nicolás Andrés Gallinal

commit sha 38b7857704436a1c8ee4b5b96e62a16ecbb5293d

Updated CompileOptionsWrapper new method to receive a &str for the filename Also changed the line parameter to u32 instead of c_int (to make the bits clearer)

view details

bors-servo

commit sha 04fd4b7066f1b1bac2de4c8ccc53a2247dcd7e86

Auto merge of #521 - servo:proxy, r=asajeffrey Support creating singleton proxy objects

view details

bors-servo

commit sha b3c252f5cb8ae6640a745ffdc8b3dd4a3005a752

Auto merge of #520 - nicoabie:fix/518, r=jdm CompileOptionsWrapper::new should accept a &str instead of a C string pointer Updated CompileOptionsWrapper new method to receive a &str for the filename Also changed the line parameter to u32 instead of c_int (to make the bits clearer) Fixes #518

view details

Anthony Ramine

commit sha cb8861ca7469f4c8f0508672a70f283540fbd8b2

Update mozjs_sys to bring the new proxy stuff

view details

push time in 3 months

pull request commentnox/serde_urlencoded

Use the new form_urlencoded crate instead of url

bors r+

jplatte

comment created time in 3 months

PR opened servo/mozjs

Bind the variables of js/Proxy.h to allow custom Proxy classes
+3 -1

0 comment

3 changed files

pr created time in 3 months

push eventservo/mozjs

Anthony Ramine

commit sha b234620eb463cda6236cce0eb1af1674ea4da234

Bind the variables of js/Proxy.h to allow custom Proxy classes

view details

push time in 3 months

create barnchservo/mozjs

branch : proxy

created branch time in 3 months

pull request commentservo/servo

build(deps): bump png from 0.16.6 to 0.16.7

@bors-servo r+

dependabot-preview[bot]

comment created time in 3 months

pull request commentservo/servo

Fire mouseenter and mouseleave events

I've checked locally and everything looks good now AFAICT.

@bors-servo r+

utsavoza

comment created time in 3 months

pull request commentservo/servo

Fire mouseenter and mouseleave events

Aha, we didn't enable pointerevents tests. You need to add this to tests/wpt/include.ini:

[pointerevents]
  skip: false

You can add it after this stuff to keep things alphabetical:

[permissions]
  skip: false
utsavoza

comment created time in 3 months

pull request commentservo/servo

Fire mouseenter and mouseleave events

The code looks correct but this will probably need changes to the test expectations.

@bors-servo try=wpt

utsavoza

comment created time in 3 months

PR opened servo/rust-mozjs

Support creating singleton proxy objects
+10 -4

0 comment

4 changed files

pr created time in 3 months

push eventservo/rust-mozjs

Josh Matthews

commit sha 831e7a390d2747bb18bef2dbc00e98ec583a2744

Support creating singleton proxy objects.

view details

push time in 3 months

pull request commenterlang/otp

Make compiler report column as well as line number

My own patches included documentation. :P

richcarl

comment created time in 3 months

pull request commentservo/servo

Layout 2020: Implement basic white-space: pre support

@bors-servo r+

jdm

comment created time in 3 months

push eventservo/rust-mozjs

Josh Matthews

commit sha e7949b8a2c47a34248b77de412e0bd43c2eeaedc

Support creating singleton proxy objects.

view details

push time in 3 months

create barnchservo/rust-mozjs

branch : proxy

created branch time in 3 months

pull request commentservo/servo

Remove unit test that triggers frequent intermittent failure.

@bors-servo r+

jdm

comment created time in 3 months

issue commentservo/rust-url

Behaviour of Url::join

"Resolve" in the node.js thing is a legacy API, the actual API is just the URL constructor with 2 arguments. I still think join is a better name for this.

theduke

comment created time in 3 months

PR closed servo/servo

build(deps): bump image from 0.23.0 to 0.23.8 S-awaiting-review dependencies

Bumps image from 0.23.0 to 0.23.8. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/image-rs/image/blob/master/CHANGES.md">image's changelog</a>.</em></p> <blockquote> <h3>Version 0.23.8</h3> <ul> <li><code>flat::Error</code> now implements the standard <code>Error</code> trait</li> <li>The type parameter of <code>Map</code> has been relaxed to <code>?Sized</code></li> <li>Added the <code>imageops::tile</code> function that repeats one image across another</li> </ul> <h3>Version 0.23.7</h3> <ul> <li>Iterators over immutable pixels of <code>ImageBuffer</code> can now be cloned</li> <li>Added a <code>tga</code> encoder</li> <li>Added <code>ColorMap::lookup</code>, an optional reversal of the map</li> <li>The <code>EncodableLayout</code> trait is now exported</li> </ul> <h3>Version 0.23.6</h3> <ul> <li>Added <code>png::ApngDecoder</code>, an adapter decoding the animation in an APNG.</li> <li>Fixed a bug in <code>jpeg</code> encoding that would darken output colors.</li> <li>Added a utility constructor <code>FlatSamples::with_monocolor</code>.</li> <li>Added <code>ImageBuffer::as_flat_samples_mut</code> which is a mutable variant of the existing ffi-helper <code>ImageBuffer::as_flat_samples</code>.</li> </ul> <h3>Version 0.23.5</h3> <ul> <li>The <code>png</code> encoder now allows configuring compression and filter type. The output is not part of stability guarantees, see its documentation.</li> <li>The <code>jpeg</code> encoder now accepts any implementor of <code>GenericImageView</code>. This allows images that are only partially present in memory to be encoded.</li> <li><code>ImageBuffer</code> now derives <code>Hash</code>, <code>PartialEq</code>, <code>Eq</code>.</li> <li>The <code>Pixels</code>/<code>PixelsMut</code> iterator no longer yields out-of-bounds pixels when the underlying buffer is larger than required.</li> <li>The <code>pbm</code> decoder correctly decodes ascii data again, fixing a regression where it would use the sample value <code>1</code> as white instead of <code>255</code>.</li> <li>Fix encoding of RGBA data in <code>gif</code> frames.</li> <li>Constructing a <code>Rows</code>/<code>RowsMut</code> iterator no longer panics when the image has a width or height of <code>0</code>.</li> </ul> <h3>Version 0.23.4</h3> <ul> <li>Improved the performance of decoding animated gifs</li> <li>Added <code>crop_imm</code> which functions like <code>crop</code> but on a shared reference</li> <li>The gif <code>DisposalMethod::Any</code> is treated as <code>Keep</code>, consistent with browsers</li> <li>Most errors no longer allocate a string, instead implement Display.</li> <li>Add some implementations of <code>Error::source</code></li> </ul> <h3>Version 0.23.3</h3> <ul> <li>Added <code>ColorType::has_alpha</code> to facilitate lossless conversion</li> <li>Recognize extended WebP formats for decoding</li> <li>Added decoding and encoding for the <code>farbfeld</code> format</li> <li>Export named iterator types created from various <code>ImageBuffer</code> methods</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/image-rs/image/commit/79b415baaa2deaa26e5af2401694ca167eb759dd"><code>79b415b</code></a> Add release notes and update meta data for 0.23.8</li> <li><a href="https://github.com/image-rs/image/commit/00776e4219cb3c39d499bb1144704c7f93945df1"><code>00776e4</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/image-rs/image/issues/1292">#1292</a> from MicroJoe/fix-warnings</li> <li><a href="https://github.com/image-rs/image/commit/ebe2e6edc67c449d5cddb40ea1f18f530d7fd444"><code>ebe2e6e</code></a> fix unused import warning in farbfeld.rs</li> <li><a href="https://github.com/image-rs/image/commit/80ca569297858c1418bc688a135105e387478527"><code>80ca569</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/image-rs/image/issues/1284">#1284</a> from MicroJoe/tile</li> <li><a href="https://github.com/image-rs/image/commit/6eea62394be1c38b97eff7053599aa274ef67638"><code>6eea623</code></a> imageops: introduce tile function</li> <li><a href="https://github.com/image-rs/image/commit/bbcda52a3b1a26553ec12867b3ef4dddd636b90d"><code>bbcda52</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/image-rs/image/issues/1289">#1289</a> from wathiede/master</li> <li><a href="https://github.com/image-rs/image/commit/ed5b3094adeb850e37115ec8bd953cb945664a24"><code>ed5b309</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/image-rs/image/issues/1290">#1290</a> from sassman/master</li> <li><a href="https://github.com/image-rs/image/commit/ac30aebac9c299e5a8a7e002e879eec423189149"><code>ac30aeb</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/image-rs/image/issues/1288">#1288</a> from HeroicKatora/error-on-flat</li> <li><a href="https://github.com/image-rs/image/commit/10591ef00f35b72d14b79e6ac2c5a8b0dfe9b3f6"><code>10591ef</code></a> doc(buffers): describe the iteration order a bit further</li> <li><a href="https://github.com/image-rs/image/commit/54054506780ead35b5c265dcf3ffffddd000f089"><code>5405450</code></a> imageops: Add <code>?Sized</code> bound to generic type <code>Map</code>.</li> <li>Additional commits viewable in <a href="https://github.com/image-rs/image/compare/v0.23.0...v0.23.8">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
  • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

  • Update frequency (including time of day and day of week)
  • Pull request limits (per update run and/or open at any time)
  • Out-of-range updates (receive only lockfile updates, if desired)
  • Security updates (receive only security updates, if desired)

</details>

+42 -9

1 comment

1 changed file

dependabot-preview[bot]

pr closed time in 3 months

pull request commentservo/servo

build(deps): bump image from 0.23.0 to 0.23.8

```./Cargo.lock:1: duplicate versions for package num-rational The following packages depend on version 0.2.4 from 'crates.io': gstreamer 0.15.7 The following packages depend on version 0.3.0 from 'crates.io': image 0.23.8 ./Cargo.lock:1: duplicate versions for package png The following packages depend on version 0.15.3 from 'crates.io': raqote 0.8.0 The following packages depend on version 0.16.7 from 'crates.io': image 0.23.8 ./Cargo.lock:1: duplicate versions for package deflate The following packages depend on version 0.7.20 from 'crates.io': png 0.15.3 The following packages depend on version 0.8.6 from 'crates.io': png 0.16.7

dependabot-preview[bot]

comment created time in 3 months

more