Parallel Deque implementation #1

Aatch · 2013-05-16T03:13:15Z

Implements the Chase and Lev work-stealing deque and changes the existing scheduler code to match.

brson · 2013-05-16T05:38:18Z

Thanks a lot. This looks amazing. I ... really need to catch up by reading this paper. I'll give the code a thorough look tomorrow.

brson · 2013-05-17T00:48:09Z

Hi, @Aatch. Thanks for working on this. I've read the first few pages of the paper and have a few observations. I'll try to get through the rest of the paper soon.

The first thing I notice is that many operations that should be atomic are not. In the code examples in the paper you can see that bottom, top and activeArray are all declared volatile. In Java, volatile means 'atomic, sequentially consistent'. That these values are atomic is why the algorithm is very particular about the order in which they are read, and why it always copies them to temporaries before operating on them. In Rust you could imagine bottom and top being declared Atomic<uint> or AtomicUInt. In lieu of those types we'll need to use atomic intrinsics.

activeArray deserves special attention because the paper relies on Java's GC to share the array while using atomics to synchronously update it's canonical shared reference (the activeArray field). In Rust it would be appropriate to put the CircularArray in an UnsafeAtomicRcBox to share the array. To store it atomically it will need another level of indirection because UnsafeAtomicRcBox is not pointer sized. The activeArray field may look something like ~UnsafeAtomicRcBox<CircularArray>. Then when threads take their own reference to it they would say something like let a: UnsafeAtomicRcBox<CircularArray> = (*activeArray).clone().

For creating parallel test cases I suggest not relying on spawn and instead use the Thread type in rt::thread. We are going to want a lot of tests that stress all the corner cases of the algorithm, e.g. the special case where popBottom empties the deque.

I'll keep studying this. Let me know if you need any further pointers.

brson · 2013-05-17T01:06:49Z

For reference here's GHC's implementation https://github.com/ghc/ghc/blob/master/rts/WSDeque.c

Aatch · 2013-05-17T01:15:11Z

Yeah, I discovered a lot of that stuff, and my threading thing was mostly because I was getting odd errors and was trying to figure out where from. I've already refactored some of it back to the original Thread impl.

I also hit the active buffer issue and realised that the GC was the issue, so I'm going to fix that too.

Aatch · 2013-05-19T06:19:57Z

I'm gonna close this while I fix stuff so it doesn't get spammed with commits...

Passing higher alignment values gives the optimization passes more freedom since it can copy in larger chunks. This change results in rustc outputting the same post-optimization IR as clang for swaps and most copies excluding the lack of information about padding. Code snippet: ```rust #[inline(never)] fn swap<T>(x: &mut T, y: &mut T) { util::swap(x, y); } ``` Original IR (for `int`): ```llvm define internal fastcc void @_ZN9swap_283417_a71830ca3ed2d65d3_00E(i64*, i64*) #1 { static_allocas: %2 = icmp eq i64* %0, %1 br i1 %2, label %_ZN4util9swap_283717_a71830ca3ed2d65d3_00E.exit, label %3 ; <label>:3 ; preds = %static_allocas %4 = load i64* %0, align 1 %5 = load i64* %1, align 1 store i64 %5, i64* %0, align 1 store i64 %4, i64* %1, align 1 br label %_ZN4util9swap_283717_a71830ca3ed2d65d3_00E.exit _ZN4util9swap_283717_a71830ca3ed2d65d3_00E.exit: ; preds = %3, %static_allocas ret void } ``` After rust-lang#6710: ```llvm define internal fastcc void @_ZN9swap_283017_a71830ca3ed2d65d3_00E(i64* nocapture, i64* nocapture) #1 { static_allocas: %2 = load i64* %0, align 1 %3 = load i64* %1, align 1 store i64 %3, i64* %0, align 1 store i64 %2, i64* %1, align 1 ret void } ``` After this change: ```llvm define internal fastcc void @_ZN9swap_283017_a71830ca3ed2d65d3_00E(i64* nocapture, i64* nocapture) #1 { static_allocas: %2 = load i64* %0, align 8 %3 = load i64* %1, align 8 store i64 %3, i64* %0, align 8 store i64 %2, i64* %1, align 8 ret void } ``` Another example: ```rust #[inline(never)] fn set<T>(x: &mut T, y: T) { *x = y; } ``` Before, with `(int, int)` (align 1): ```llvm define internal fastcc void @_ZN8set_282517_8fa972e3f9e451983_00E({ i64, i64 }* nocapture, { i64, i64 }* nocapture) #1 { static_allocas: %2 = bitcast { i64, i64 }* %1 to i8* %3 = bitcast { i64, i64 }* %0 to i8* tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 1, i1 false) ret void } ``` After, with `(int, int)` (align 8): ```llvm define internal fastcc void @_ZN8set_282617_8fa972e3f9e451983_00E({ i64, i64 }* nocapture, { i64, i64 }* nocapture) #1 { static_allocas: %2 = bitcast { i64, i64 }* %1 to i8* %3 = bitcast { i64, i64 }* %0 to i8* tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 8, i1 false) ret void } ```

This allows LLVM to optimize vector iterators to an `getelementptr` and `icmp` pair, instead of `getelementptr` and *two* comparisons. Code snippet: ~~~ fn foo(xs: &mut [f64]) { for x in xs.mut_iter() { *x += 10.0; } } ~~~ LLVM IR at stage0: ~~~ ; Function Attrs: noinline uwtable define void @"_ZN3foo17_68e1b25bca131dba7_0$x2e0E"({ i64, %tydesc*, i8*, i8*, i8 }* nocapture, { double*, i64 }* nocapture) #1 { "function top level": %2 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 0 %3 = load double** %2, align 8 %4 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 1 %5 = load i64* %4, align 8 %6 = ptrtoint double* %3 to i64 %7 = and i64 %5, -8 %8 = add i64 %7, %6 %9 = inttoptr i64 %8 to double* %10 = icmp eq double* %3, %9 %11 = icmp eq double* %3, null %or.cond6 = or i1 %10, %11 br i1 %or.cond6, label %match_case, label %match_else match_else: ; preds = %"function top level", %match_else %12 = phi double* [ %13, %match_else ], [ %3, %"function top level" ] %13 = getelementptr double* %12, i64 1 %14 = load double* %12, align 8 %15 = fadd double %14, 1.000000e+01 store double %15, double* %12, align 8 %16 = icmp eq double* %13, %9 %17 = icmp eq double* %13, null %or.cond = or i1 %16, %17 br i1 %or.cond, label %match_case, label %match_else match_case: ; preds = %match_else, %"function top level" ret void } ~~~ Optimized LLVM IR at stage1/stage2: ~~~ ; Function Attrs: noinline uwtable define void @"_ZN3foo17_68e1b25bca131dba7_0$x2e0E"({ i64, %tydesc*, i8*, i8*, i8 }* nocapture, { double*, i64 }* nocapture) #1 { "function top level": %2 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 0 %3 = load double** %2, align 8 %4 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 1 %5 = load i64* %4, align 8 %6 = lshr i64 %5, 3 %7 = getelementptr inbounds double* %3, i64 %6 %8 = icmp eq i64 %6, 0 %9 = icmp eq double* %3, null %or.cond6 = or i1 %8, %9 br i1 %or.cond6, label %match_case, label %match_else match_else: ; preds = %"function top level", %match_else %.sroa.0.0.in7 = phi double* [ %10, %match_else ], [ %3, %"function top level" ] %10 = getelementptr inbounds double* %.sroa.0.0.in7, i64 1 %11 = load double* %.sroa.0.0.in7, align 8 %12 = fadd double %11, 1.000000e+01 store double %12, double* %.sroa.0.0.in7, align 8 %13 = icmp eq double* %10, %7 br i1 %13, label %match_case, label %match_else match_case: ; preds = %match_else, %"function top level" ret void } ~~~

This brings Rust in line with how `clang` handles return pointers. Example: pub fn bar() -> [uint, .. 8] { let a = [0, .. 8]; a } Before: ; Function Attrs: nounwind uwtable define void @_ZN3bar17ha4635c6f704bfa334v0.0E([8 x i64]* nocapture, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #1 { "function top level": %a = alloca [8 x i64], align 8 %2 = bitcast [8 x i64]* %a to i8* call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 64, i32 8, i1 false) %3 = bitcast [8 x i64]* %0 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 64, i32 8, i1 false) ret void } After: ; Function Attrs: nounwind uwtable define void @_ZN3bar17ha4635c6f704bfa334v0.0E([8 x i64]* noalias nocapture sret, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #1 { "function top level": %2 = bitcast [8 x i64]* %0 to i8* call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 64, i32 8, i1 false) ret void } Closes rust-lang#9072 Closes rust-lang#7298 Closes rust-lang#9154

C-like enums are excluded from this for now, because the code paths specific to them need to be changed. fn foo() -> Option<~int> { Some(~5) } Before: ; Function Attrs: uwtable define void @_ZN3foo18hdec6e36682b87eeaf4v0.0E(%"enum.std::option::Option<~int>[#1]"* noalias nocapture sret, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #0 { "function top level": %2 = tail call %"enum.std::libc::types::common::c95::c_void[#1]"* @"_ZN2rt11global_heap10malloc_raw17h56c543b77f9b78aY11v0.9$x2dpreE"({ i64, %tydesc*, i8*, i8*, i8 }* undef, i64 8) %3 = bitcast %"enum.std::libc::types::common::c95::c_void[#1]"* %2 to i64* store i64 5, i64* %3, align 8 %4 = getelementptr inbounds %"enum.std::option::Option<~int>[#1]"* %0, i64 0, i32 0 store i64* %3, i64** %4, align 8 ret void } After: ; Function Attrs: uwtable define %"enum.std::option::Option<~int>[#1]" @_ZN3foo18h2cbf6557a3143edah4v0.0E({ i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #0 { "function top level": %1 = tail call %"enum.std::libc::types::common::c95::c_void[#1]"* @"_ZN2rt11global_heap10malloc_raw18hb1e9dd1beab35edau11v0.9$x2dpreE"({ i64, %tydesc*, i8*, i8*, i8 }* undef, i64 8) %2 = bitcast %"enum.std::libc::types::common::c95::c_void[#1]"* %1 to i64* store i64 5, i64* %2, align 8 %oldret = insertvalue %"enum.std::option::Option<~int>[#1]" undef, i64* %2, 0 ret %"enum.std::option::Option<~int>[#1]" %oldret }

Example: void ({ i64, %tydesc*, i8*, i8*, i8 }*, i64*, %"struct.std::fmt::Formatter[#1]"*)* Before, we would print 20 levels deep due to recursion in the type definition.

@eat

Function parameters that are to be passed by value but don't fit into a single register are currently passed by creating a copy on the stack and passing a pointer to that copy to the callee. Since the copy is made just for the function call, there are no aliases. For example, this sometimes allows LLVM to eliminate unnecessary calls to drop glue. Given ````rust struct Foo { a: int, b: Option<~str>, } extern { fn eat(eat: Option<~str>); } pub fn foo(v: Foo) { match v { Foo { a: _, b } => unsafe { eat(b) } } } ```` LLVM currently can't eliminate the drop call for the string, because it only sees a _pointer_ to Foo, for which it has to expect an alias. So we get: ````llvm ; Function Attrs: uwtable define void @_ZN3foo20h9f32c90ae7201edbxaa4v0.0E(%struct.Foo* nocapture) unnamed_addr #0 { "_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit": %1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0 %2 = load { i64, i64, [0 x i8] }** %1, align 8 store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8 %3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64 %.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0 tail call void @eat({ i64 } %.fca.0.insert) %4 = load { i64, i64, [0 x i8] }** %1, align 8 %5 = icmp eq { i64, i64, [0 x i8] }* %4, null br i1 %5, label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit, label %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i" "_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i": ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit" %6 = bitcast { i64, i64, [0 x i8] }* %4 to i8* tail call void @free(i8* %6) #1 br label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit _ZN3Foo9glue_drop17hf611996539d3036fE.exit: ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit", %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i" ret void } ```` But with the `noalias` attribute, it can safely optimize that to: ````llvm define void @_ZN3foo20hd28431f929f0d6c4xaa4v0.0E(%struct.Foo* noalias nocapture) unnamed_addr #0 { _ZN3Foo9glue_drop17he9afbc09d4e9c851E.exit: %1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0 %2 = load { i64, i64, [0 x i8] }** %1, align 8 store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8 %3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64 %.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0 tail call void @eat({ i64 } %.fca.0.insert) ret void } ````

@eat

Function parameters that are to be passed by value but don't fit into a single register are currently passed by creating a copy on the stack and passing a pointer to that copy to the callee. Since the copy is made just for the function call, there are no aliases. For example, this sometimes allows LLVM to eliminate unnecessary calls to drop glue. Given ````rust struct Foo { a: int, b: Option<~str>, } extern { fn eat(eat: Option<~str>); } pub fn foo(v: Foo) { match v { Foo { a: _, b } => unsafe { eat(b) } } } ```` LLVM currently can't eliminate the drop call for the string, because it only sees a _pointer_ to Foo, for which it has to expect an alias. So we get: ````llvm ; Function Attrs: uwtable define void @_ZN3foo20h9f32c90ae7201edbxaa4v0.0E(%struct.Foo* nocapture) unnamed_addr #0 { "_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit": %1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0 %2 = load { i64, i64, [0 x i8] }** %1, align 8 store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8 %3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64 %.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0 tail call void @eat({ i64 } %.fca.0.insert) %4 = load { i64, i64, [0 x i8] }** %1, align 8 %5 = icmp eq { i64, i64, [0 x i8] }* %4, null br i1 %5, label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit, label %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i" "_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i": ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit" %6 = bitcast { i64, i64, [0 x i8] }* %4 to i8* tail call void @free(i8* %6) #1 br label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit _ZN3Foo9glue_drop17hf611996539d3036fE.exit: ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit", %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i" ret void } ```` But with the `noalias` attribute, it can safely optimize that to: ````llvm define void @_ZN3foo20hd28431f929f0d6c4xaa4v0.0E(%struct.Foo* noalias nocapture) unnamed_addr #0 { _ZN3Foo9glue_drop17he9afbc09d4e9c851E.exit: %1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0 %2 = load { i64, i64, [0 x i8] }** %1, align 8 store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8 %3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64 %.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0 tail call void @eat({ i64 } %.fca.0.insert) ret void } ````

This includes a change to the way lifetime names are generated. Say we figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead of just generating a new lifetime `'c` like before to replace them, we would reuse `'a`. This is done so that when the lifetime name comes from an impl, we don't give something that's completely off, and we don't have to do much work to figure out where the name came from. For example, for the following code snippet: ```rust struct Baz<'x> { bar: &'x int } impl<'x> Baz<'x> { fn baz1(&self) -> &int { self.bar } } ``` `[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`) have to be marked the same lifetime. With the old method, we would generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int` or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.

…d, r=nmatsakis This includes a change to the way lifetime names are generated. Say we figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead of just generating a new lifetime `'c` like before to replace them, we would reuse `'a`. This is done so that when the lifetime name comes from an impl, we don't give something that's completely off, and we don't have to do much work to figure out where the name came from. For example, for the following code snippet: ```rust struct Baz<'x> { bar: &'x int } impl<'x> Baz<'x> { fn baz1(&self) -> &int { self.bar } } ``` `[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`) have to be marked the same lifetime. With the old method, we would generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int` or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.

Suggested revisions to PR 13676.

@bar

```Rust struct With { x: int, f: NoCopy } #[no_mangle] fn bar() { let mine = With { x: 3, f: NoCopy }; match mine { c => { foo(c); } } } #[no_mangle] fn foo(_: With) {} ``` Before: ```LLVM define internal void @bar() unnamed_addr #1 { entry-block: %mine = alloca %"struct.With<[]>" %__llmatch = alloca %"struct.With<[]>"* %c = alloca %"struct.With<[]>" %0 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 0 store i64 3, i64* %0 %1 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 1 store %"struct.With<[]>"* %mine, %"struct.With<[]>"** %__llmatch br label %case_body case_body: ; preds = %entry-block %2 = load %"struct.With<[]>"** %__llmatch %3 = bitcast %"struct.With<[]>"* %2 to i8* %4 = bitcast %"struct.With<[]>"* %c to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %4, i8* %3, i64 8, i32 8, i1 false) %5 = load %"struct.With<[]>"* %c call void @foo(%"struct.With<[]>" %5) br label %join join: ; preds = %case_body ret void } ``` After: ```LLVM define internal void @bar() unnamed_addr #1 { entry-block: %mine = alloca %"struct.With<[]>" %c = alloca %"struct.With<[]>"* %0 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 0 store i64 3, i64* %0 %1 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 1 store %"struct.With<[]>"* %mine, %"struct.With<[]>"** %c br label %case_body case_body: ; preds = %entry-block %2 = load %"struct.With<[]>"** %c %3 = load %"struct.With<[]>"* %2 call void @foo(%"struct.With<[]>" %3) br label %join join: ; preds = %case_body ret void } ``` r? @pcwalton

…ariables Diagnostics such as the following ``` mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut <generic #2>`, found `uint` <anon>:7 f(42u); ^~~ ``` tend to be fairly unappealing to new users. While specific type var IDs are valuable in diagnostics that deal with more than one such variable, in practice many messages only mention one. In those cases, leaving out the specific number makes the messages slightly less terrifying. In addition, type variables have been changed to use the type hole syntax `_` in diagnostics. With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out, it's simply `_`. Integer and float variables have an additional suffix after the number, e.g. `_#1i` or `_#3f`.

…, r=nikomatsakis This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following: ```rust mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut <generic #2>`, found `uint` <anon>:7 f(42u); ^~~ ``` tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in diagnostics that deal with more than one such variable, in practice many messages only mention one. In those cases, leaving out the specific number makes the messages slightly less terrifying. ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut _`, found `uint` <anon>:7 f(42u); ^~~ ``` As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is: ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>` <anon>:6 let a: Result<uint, ()> = Some(1); ``` and float variables: ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>` <anon>:6 let a: Result<uint, ()> = Some(0.5); ``` [0] https://twitter.com/coda/status/517713085465772032 Closes rust-lang#2632. Closes rust-lang#3404. Closes rust-lang#18426.

Update from original

Fixes rust-lang#19707. In terms of output, it currently uses the form `argument #1`, `argument #2`, etc. If anyone has any better suggestions I would be glad to consider them.

fix double "however"

…hange Change verbiage in Stack & Heap page

update tests emitter.rs

Change import a trait suggestion from: help: candidate #1: use `std::io::Write` to help: candidate #1: `use std::io::Write` so that the code can be copied directly.

suggest: Put the `use` in suggested code inside the quotes Change import a trait suggestion from: help: candidate #1: use `std::io::Write` to help: candidate #1: `use std::io::Write` so that the code can be copied directly. Fixes rust-lang#31864

Save ids fix

rustc_trans: don't Assert(Overflow(Neg)) when overflow checks are off. Generic functions using `Neg` on primitive types would panic even in release mode, with MIR trans. The solution is a bit hacky, as I'm checking the message, since there's no dedicated `CheckedUnOp`. Blocks Servo rustup ([failure #1](http://build.servo.org/builders/linux-rel/builds/2477/steps/test_3/logs/stdio), [failure #2](http://build.servo.org/builders/mac-rel-css/builds/2364/steps/test/logs/stdio)) - this should be the last hurdle, it affects only one test.

For a given file ```rust trait A { fn foo(&self) {} } trait B : A { fn foo(&self) {} } fn bar<T: B>(a: &T) { a.foo() } ``` provide the following output ``` error[E0034]: multiple applicable items in scope --> file.rs:6:5 | 6 | a.foo(1) | ^^^ multiple `foo` found | note: candidate #1 is defined in the trait `A` --> file.rs:2:11 | 2 | trait A { fn foo(&self, a: usize) {} } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to use it here write `A::foo(&a, 1)` instead --> file.rs:6:5 | 6 | a.foo(1) | ^^^ note: candidate #2 is defined in the trait `B` --> file.rs:3:15 | 3 | trait B : A { fn foo(&self, a: usize) {} } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to use it here write `B::foo(&a, 1)` instead --> file.rs:6:5 | 6 | a.foo(1) | ^^^ ```

E0034: provide disambiguated syntax for candidates For a given file ```rust trait A { fn foo(&self) {} } trait B : A { fn foo(&self) {} } fn bar<T: B>(a: &T) { a.foo() } ``` provide the following output ``` error[E0034]: multiple applicable items in scope --> file.rs:6:5 | 6 | a.foo(1) | ^^^ multiple `foo` found | note: candidate #1 is defined in the trait `A` --> file.rs:2:11 | 2 | trait A { fn foo(&self, a: usize) {} } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to use it here write `A::foo(&a, 1)` instead --> file.rs:6:5 | 6 | a.foo(1) | ^^^ note: candidate #2 is defined in the trait `B` --> file.rs:3:15 | 3 | trait B : A { fn foo(&self, a: usize) {} } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to use it here write `B::foo(&a, 1)` instead --> file.rs:6:5 | 6 | a.foo(1) | ^^^ ``` Fix rust-lang#37767.

LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support ``` $ cargo new --bin leak && cd $_ $ edit Cargo.toml && tail -n3 $_ ``` ``` toml [profile.dev] opt-level = 1 ``` ``` $ edit src/main.rs && cat $_ ``` ``` rust use std::mem; fn main() { let xs = vec![0, 1, 2, 3]; mem::forget(xs); } ``` ``` $ RUSTFLAGS="-Z sanitizer=leak" cargo run --target x86_64-unknown-linux-gnu; echo $? Finished dev [optimized + debuginfo] target(s) in 0.0 secs Running `target/debug/leak` ================================================================= ==10848==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x557c3488db1f in __interceptor_malloc /shared/rust/checkouts/lsan/src/compiler-rt/lib/lsan/lsan_interceptors.cc:55 #1 0x557c34888aaa in alloc::heap::exchange_malloc::h68f3f8b376a0da42 /shared/rust/checkouts/lsan/src/liballoc/heap.rs:138 #2 0x557c34888afc in leak::main::hc56ab767de6d653a $PWD/src/main.rs:4 #3 0x557c348c0806 in __rust_maybe_catch_panic ($PWD/target/debug/leak+0x3d806) SUMMARY: LeakSanitizer: 16 byte(s) leaked in 1 allocation(s). 23 ``` ``` $ cargo new --bin racy && cd $_ $ edit src/main.rs && cat $_ ``` ``` rust use std::thread; static mut ANSWER: i32 = 0; fn main() { let t1 = thread::spawn(|| unsafe { ANSWER = 42 }); unsafe { ANSWER = 24; } t1.join().ok(); } ``` ``` $ RUSTFLAGS="-Z sanitizer=thread" cargo run --target x86_64-unknown-linux-gnu; echo $? ================== WARNING: ThreadSanitizer: data race (pid=12019) Write of size 4 at 0x562105989bb4 by thread T1: #0 racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e $PWD/src/main.rs:6 (racy+0x000000010e3f) #1 _$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h2e466a92accacc78 /shared/rust/checkouts/lsan/src/libstd/panic.rs:296 (racy+0x000000010cc5) #2 std::panicking::try::do_call::h7f4d2b38069e4042 /shared/rust/checkouts/lsan/src/libstd/panicking.rs:460 (racy+0x00000000c8f2) #3 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56) #4 std::panic::catch_unwind::h31ca45621ad66d5a /shared/rust/checkouts/lsan/src/libstd/panic.rs:361 (racy+0x00000000b517) #5 std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::hccfc37175dea0b01 /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:357 (racy+0x00000000c226) #6 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::hd880bbf91561e033 /shared/rust/checkouts/lsan/src/liballoc/boxed.rs:605 (racy+0x00000000f27e) #7 std::sys::imp::thread::Thread::new::thread_start::hebdfc4b3d17afc85 <null> (racy+0x0000000abd40) Previous write of size 4 at 0x562105989bb4 by main thread: #0 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:8 (racy+0x000000010d7c) #1 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56) #2 __libc_start_main <null> (libc.so.6+0x000000020290) Location is global 'racy::ANSWER::h543d2b139f819b19' of size 4 at 0x562105989bb4 (racy+0x0000002f8bb4) Thread T1 (tid=12028, running) created by main thread at: #0 pthread_create /shared/rust/checkouts/lsan/src/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:902 (racy+0x00000001aedb) #1 std::sys::imp::thread::Thread::new::hce44187bf4a36222 <null> (racy+0x0000000ab9ae) #2 std::thread::spawn::he382608373eb667e /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:412 (racy+0x00000000b5aa) #3 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:6 (racy+0x000000010d5c) #4 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56) #5 __libc_start_main <null> (libc.so.6+0x000000020290) SUMMARY: ThreadSanitizer: data race $PWD/src/main.rs:6 in racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e ================== ThreadSanitizer: reported 1 warnings 66 ``` ``` $ cargo new --bin oob && cd $_ $ edit src/main.rs && cat $_ ``` ``` rust fn main() { let xs = [0, 1, 2, 3]; let y = unsafe { *xs.as_ptr().offset(4) }; } ``` ``` $ RUSTFLAGS="-Z sanitizer=address" cargo run --target x86_64-unknown-linux-gnu; echo $? ================================================================= ==13328==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff29f3ecd0 at pc 0x55802dc6bf7e bp 0x7fff29f3ec90 sp 0x7fff29f3ec88 READ of size 4 at 0x7fff29f3ecd0 thread T0 #0 0x55802dc6bf7d in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:3 #1 0x55802dd60426 in __rust_maybe_catch_panic ($PWD/target/debug/oob+0xfe426) #2 0x55802dd58dd9 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/oob+0xf6dd9) #3 0x55802dc6c002 in main ($PWD/target/debug/oob+0xa002) #4 0x7fad8c3b3290 in __libc_start_main (/usr/lib/libc.so.6+0x20290) #5 0x55802dc6b719 in _start ($PWD/target/debug/oob+0x9719) Address 0x7fff29f3ecd0 is located in stack of thread T0 at offset 48 in frame #0 0x55802dc6bd5f in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:1 This frame has 1 object(s): [32, 48) 'xs' <== Memory access at offset 48 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow $PWD/src/main.rs:3 in oob::main::h0adc7b67e5feb2e7 Shadow bytes around the buggy address: 0x1000653dfd40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x1000653dfd90: 00 00 00 00 f1 f1 f1 f1 00 00[f3]f3 00 00 00 00 0x1000653dfda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfdd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfde0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==13328==ABORTING 1 ``` ``` $ cargo new --bin uninit && cd $_ $ edit src/main.rs && cat $_ ``` ``` rust use std::mem; fn main() { let xs: [u8; 4] = unsafe { mem::uninitialized() }; let y = xs[0] + xs[1]; } ``` ``` $ RUSTFLAGS="-Z sanitizer=memory" cargo run; echo $? ==30198==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x563f4b6867da in uninit::main::hc2731cd4f2ed48f8 $PWD/src/main.rs:5 #1 0x563f4b7033b6 in __rust_maybe_catch_panic ($PWD/target/debug/uninit+0x873b6) #2 0x563f4b6fbd69 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/uninit+0x7fd69) #3 0x563f4b6868a9 in main ($PWD/target/debug/uninit+0xa8a9) #4 0x7fe844354290 in __libc_start_main (/usr/lib/libc.so.6+0x20290) #5 0x563f4b6864f9 in _start ($PWD/target/debug/uninit+0xa4f9) SUMMARY: MemorySanitizer: use-of-uninitialized-value $PWD/src/main.rs:5 in uninit::main::hc2731cd4f2ed48f8 Exiting 77 ```

Group "missing variable bind" spans in `or` matches and clarify wording for the two possible cases: when a variable from the first pattern is not in any of the subsequent patterns, and when a variable in any of the other patterns is not in the first one. Before: ``` error[E0408]: variable `a` from pattern #1 is not bound in pattern #2 --> file.rs:10:23 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^^^^ pattern doesn't bind `a` error[E0408]: variable `b` from pattern #2 is not bound in pattern #1 --> file.rs:10:32 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^ pattern doesn't bind `b` error[E0408]: variable `a` from pattern #1 is not bound in pattern #3 --> file.rs:10:37 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^ pattern doesn't bind `a` error[E0408]: variable `d` from pattern #1 is not bound in pattern #3 --> file.rs:10:37 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^ pattern doesn't bind `d` error[E0408]: variable `c` from pattern #3 is not bound in pattern #1 --> file.rs:10:43 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^ pattern doesn't bind `c` error[E0408]: variable `d` from pattern #1 is not bound in pattern #4 --> file.rs:10:48 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^ pattern doesn't bind `d` error: aborting due to 6 previous errors ``` After: ``` error[E0408]: variable `a` is not bound in all patterns --> file.rs:20:37 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { intln!("{:?}", a); } | - ^^^^^^^^^^^ ^^^^^^^^ - variable t in all patterns | | | | | | | pattern doesn't bind `a` | | pattern doesn't bind `a` | variable not in all patterns error[E0408]: variable `d` is not bound in all patterns --> file.rs:20:37 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { intln!("{:?}", a); } | - - ^^^^^^^^ ^^^^^^^^ pattern esn't bind `d` | | | | | | | pattern doesn't bind `d` | | variable not in all patterns | variable not in all patterns error[E0408]: variable `b` is not bound in all patterns --> file.rs:20:37 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { intln!("{:?}", a); } | ^^^^^^^^^^^ - ^^^^^^^^ ^^^^^^^^ pattern esn't bind `b` | | | | | | | pattern doesn't bind `b` | | variable not in all patterns | pattern doesn't bind `b` error[E0408]: variable `c` is not bound in all patterns --> file.rs:20:48 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { intln!("{:?}", a); } | ^^^^^^^^^^^ ^^^^^^^^^^^ - ^^^^^^^^ pattern esn't bind `c` | | | | | | | variable not in all tterns | | pattern doesn't bind `c` | pattern doesn't bind `c` error: aborting due to 4 previous errors ``` * Have only one presentation for binding consistency errors * Point to same binding in multiple patterns when possible * Check inconsistent bindings in all arms * Simplify wording of diagnostic message * Sort emition and spans of binding errors for deterministic output

Clean up "pattern doesn't bind x" messages Group "missing variable bind" spans in `or` matches and clarify wording for the two possible cases: when a variable from the first pattern is not in any of the subsequent patterns, and when a variable in any of the other patterns is not in the first one. Before: ```rust error[E0408]: variable `a` from pattern #1 is not bound in pattern #2 --> file.rs:10:23 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^^^^ pattern doesn't bind `a` error[E0408]: variable `b` from pattern #2 is not bound in pattern #1 --> file.rs:10:32 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^ pattern doesn't bind `b` error[E0408]: variable `a` from pattern #1 is not bound in pattern #3 --> file.rs:10:37 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^ pattern doesn't bind `a` error[E0408]: variable `d` from pattern #1 is not bound in pattern #3 --> file.rs:10:37 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^ pattern doesn't bind `d` error[E0408]: variable `c` from pattern #3 is not bound in pattern #1 --> file.rs:10:43 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^ pattern doesn't bind `c` error[E0408]: variable `d` from pattern #1 is not bound in pattern #4 --> file.rs:10:48 | 10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^ pattern doesn't bind `d` error: aborting due to 6 previous errors ``` After: ```rust error[E0408]: variable `d` is not bound in all patterns --> $DIR/issue-39698.rs:20:37 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | - - ^^^^^^^^ ^^^^^^^^ pattern doesn't bind `d` | | | | | | | pattern doesn't bind `d` | | variable not in all patterns | variable not in all patterns error[E0408]: variable `c` is not bound in all patterns --> $DIR/issue-39698.rs:20:48 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^^^^ ^^^^^^^^^^^ - ^^^^^^^^ pattern doesn't bind `c` | | | | | | | variable not in all patterns | | pattern doesn't bind `c` | pattern doesn't bind `c` error[E0408]: variable `a` is not bound in all patterns --> $DIR/issue-39698.rs:20:37 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | - ^^^^^^^^^^^ ^^^^^^^^ - variable not in all patterns | | | | | | | pattern doesn't bind `a` | | pattern doesn't bind `a` | variable not in all patterns error[E0408]: variable `b` is not bound in all patterns --> $DIR/issue-39698.rs:20:37 | 20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); } | ^^^^^^^^^^^ - ^^^^^^^^ ^^^^^^^^ pattern doesn't bind `b` | | | | | | | pattern doesn't bind `b` | | variable not in all patterns | pattern doesn't bind `b` error: aborting due to 4 previous errors ``` Fixes rust-lang#39698.

Without that flag, LLVM generates unaligned memory access instructions, which are not allowed on ARMv5. For example, the 'hello world' example from `cargo --new` failed with: ``` $ ./hello Hello, world! thread 'main' panicked at 'assertion failed: end <= len', src/libcollections/vec.rs:1113 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` I traced this error back to the following assembler code in `BufWriter::flush_buf`: ``` 6f44: e28d0018 add r0, sp, #24 [...] 6f54: e280b005 add fp, r0, #5 [...] 7018: e5cd001c strb r0, [sp, #28] 701c: e1a0082a lsr r0, sl, #16 7020: 03a01001 moveq r1, #1 7024: e5cb0002 strb r0, [fp, #2] 7028: e1cba0b0 strh sl, [fp] ``` Note that `fp` points to `sp + 29`, so the three `str*`-instructions should fill up a 32bit - value at `sp + 28`, which is later used as the value `n` in `Ok(n) => written += n`. This doesn't work on ARMv5 as the `strh` can't write to the unaligned contents of `fp`, so the upper bits of `n` won't get cleared, leading to the assertion failure in Vec::drain. With `+strict-align`, the code works as expected.

ARMv5 needs +strict-align Without that flag, LLVM generates unaligned memory access instructions, which are not allowed on ARMv5. For example, the 'hello world' example from `cargo --new` failed with: ``` $ ./hello Hello, world! thread 'main' panicked at 'assertion failed: end <= len', src/libcollections/vec.rs:1113 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` I traced this error back to the following assembler code in `BufWriter::flush_buf`: ``` 6f44: e28d0018 add r0, sp, #24 [...] 6f54: e280b005 add fp, r0, #5 [...] 7018: e5cd001c strb r0, [sp, #28] 701c: e1a0082a lsr r0, sl, #16 7020: 03a01001 moveq r1, #1 7024: e5cb0002 strb r0, [fp, #2] 7028: e1cba0b0 strh sl, [fp] ``` Note that `fp` points to `sp + 29`, so the three `str*`-instructions should fill up a 32bit - value at `sp + 28`, which is later used as the value `n` in `Ok(n) => written += n`. This doesn't work on ARMv5 as the `strh` can't write to the unaligned contents of `fp`, so the upper bits of `n` won't get cleared, leading to the assertion failure in Vec::drain. With `+strict-align`, the code works as expected.

brson and others added 2 commits May 16, 2013 20:04

core::rt: implement oneshot and stream.

4b326d8

Implement work-stealing deque for task queue

41679d5

Aatch closed this May 19, 2013

Aatch deleted the par-deque branch May 19, 2013 06:20

brson pushed a commit that referenced this pull request Oct 14, 2013

have LLVM print type strings for us

7bad416

Example: void ({ i64, %tydesc*, i8*, i8*, i8 }*, i64*, %"struct.std::fmt::Formatter[#1]"*)* Before, we would print 20 levels deep due to recursion in the type definition.

brson pushed a commit that referenced this pull request May 7, 2014

Merge pull request #1 from pnkfelix/clarify-omit-unit-vs-inference

b3d7aa3

Suggested revisions to PR 13676.

brson pushed a commit that referenced this pull request Nov 25, 2014

Merge pull request #1 from rust-lang/master

46bdb45

Update from original

brson pushed a commit that referenced this pull request Jul 30, 2015

Merge pull request #1 from Manishearth/patch-1

9997a6e

fix double "however"

brson pushed a commit that referenced this pull request Dec 2, 2015

Merge pull request #1 from bhargavrpatel/master-stack-heap-verbiage-c…

968adb2

…hange Change verbiage in Stack & Heap page

brson pushed a commit that referenced this pull request Feb 6, 2016

Merge pull request #1 from mitaa/patch-1

c511d36

update tests emitter.rs

alexcrichton pushed a commit that referenced this pull request May 24, 2016

Merge pull request #1 from nrc/save-ids-fix

192e336

Save ids fix

brson pushed a commit that referenced this pull request Mar 4, 2017

Fix tests on Windows (#1)

227eab0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Parallel Deque implementation #1

Parallel Deque implementation #1

Uh oh!

Aatch commented May 16, 2013

Uh oh!

brson commented May 16, 2013

Uh oh!

brson commented May 17, 2013

Uh oh!

brson commented May 17, 2013

Uh oh!

Aatch commented May 17, 2013

Uh oh!

Aatch commented May 19, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Parallel Deque implementation #1

Parallel Deque implementation #1

Uh oh!

Conversation

Aatch commented May 16, 2013

Uh oh!

brson commented May 16, 2013

Uh oh!

brson commented May 17, 2013

Uh oh!

brson commented May 17, 2013

Uh oh!

Aatch commented May 17, 2013

Uh oh!

Aatch commented May 19, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants