>> The syntax was pioneered before the RFC process was in effect, so it
>> may not have an official grammar, but it looks something like:
>>
>> expr := 'box' expr | 'box' '(' expr ')' expr
>>
>> The first form is "rewritten" as `box(::std::owned::HEAP) expr` and
>> the second form (the more gen
>> Feel free to open a bug on the
>> issue tracker (https://github.com/rust-lang/rfcs/issues) or even open
>> an RFC on it! Due to it being a language change, you should register
>> the issue in the RFC repo instead of the rust repo.
>
> Oh my, I'm allowed to start an RFC? I don't feel confident i
> Disclaimer: please take all of this with a huge grain of salt. This
> feedback is meant with the humility of someone who surely doesn't
> fully understand the language yet and hasn't invested enough time into
> yet to be taken seriously. Much of what I say may have little bearing
> on anything.
>> There's a cron job running which will trigger each build each night
>> after the nightlies have finished building, and the .travis.yml script
>> for these repos are all wired to nightlies rather than the PPA.
>
>
> Could the source code for this cron job be published, with instructions on
> how
> Ok, I got the basic going with a temporary for of `libsemver` here:
> - https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706
> - https://github.com/errordeveloper/rust-libsemver
Awesome! I've created a new repo for you to make a PR against:
https://github.com/rust-lang/semver
>> We plan to implement any necessary infrastructure to ensure that the
>> crates
>> move out of the rust repository maintain the same level of quality they
>> currently have.
>
>
> Will these crates’ documentation be available online?
At this time there are no plans for this, but we're certainly
Currently the threshold for being "officially supported" will be one
of being in the rust-lang organization or being on the travis
dashboard. At this time there are no plans to have an in-tree way to
distinguish, although I suspect that a README with a description would
likely suffice.
On Tue, Jul
Now that cargo is starting to become a larger part of the Rust ecosystem
it's time for some of the crates as part of the standard distribution to
move out of the main rust repository. This movement has been planned for
quite some time now, and it has only recently become possible with the
advent of
There is not currently a method of doing so through the `std::io`
apis. While possible through the rustuv and native apis, I would
discourage manual use of those crates as they have experimental and
volatile APIs.
You may be interested in https://github.com/rust-lang/rust/pull/15643
which may add
> LD_LIBRARY_PATH is not known about by many
The install.sh script now recommends adding an entry to this variable
if it detects that this is necessary, so it's not *entirely* unknown.
This doesn't help, however, if it's considered a bad practice.
> 1) Link dependencies of rustc statically to it?
This is a known performance bug in the green schedulers being tracked
at https://github.com/rust-lang/rust/issues/11730.
To see the difference, you can run with RUST_THREADS=1 when using the
green scheduler.
On Fri, Jul 11, 2014 at 1:39 PM, Chandru wrote:
> I tried the rust-http's comparison wit
By default, each stack is allocated with a "red zone" at the end for
running code on stack overflow, calling C functions, etc. The current
size of the red zone is 20K.
Requested stack sizes are always at least 20K, but the 20K is not
currently added to the stack size. So for your test case when yo
Doc tests are compiled as if they were clients of a library, so you'll
have to write the test assuming the rest of the source was built with
`--crate-type lib` and then import it directly.
For example, you may have to do this:
```rust
main::under_test();
```
Doc test aren't really designed with
It is indeed! You'll need to ensure that
`/Users/ilya/Library/Local/Rust/current/lib` is in your
DYLD_LIBRARY_PATH environment variable for OSX.
On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
wrote:
> Is the following error cause by this change?
>
> % rustc -v
> dyld: Library not loaded:
> x86
> I am thinking that maybe one solution could be that the C code calls
> an init function that calls native::start and provides a function pointer
> that start calls back into C. That way the C main thread will have a rust
> runtime in the background, I *think*?.
That is correct!
> I hope this wo
If you touch runtime services (such as those mentioned by Benjamin),
it is assume that a Rust Task [1] is available. In your case, you're
touching the unwinding service, but you have no set a catch-point for
the call to unwinding anywhere. This sounds like you're triggering a
failure without a task
ntributors to Rust 0.11.0
---
Aaron Raimist
Aaron Turon
Adolfo Ochagavía
Adrien Tétar
Ahmed Charles
Alan Andrade
Alan Williams
Alex Crichton
Alexandre Gagnon
Alexei Sholik
Ali Smesseim
Andrew Gallant
Anton Löfgren
Arcterus
Ariel Ben-Yehuda
Axel Viala
Ben No
Binding by ref is subtly different that the function still owns the
argument. For example, this may go awry with "ref:T"
struct Foo;
impl Drop for Foo {
fn drop(&mut self) { println!("dropping"); }
}
fn foo(ref _param: Foo) {}
fn main() {
let f1: fn(ref:Foo) = foo;
let f2: fn(Foo) =
Hello Rustilians!
Bors has outdone himself once again in preparing an 0.11.0 release candidate
for us. I've done the usual smoke test, but if you'd also like to try them
out the links are all pasted below. Remember that this is not a signed
release yet, we've only got checksums for these files at
Nice job Valerii! This is all thanks to the awesome work you've been
doing wrangling compiler-rt and the standard libraries. I'm excited to
see what new applications Rust can serve on iOS!
On Mon, Jun 16, 2014 at 9:19 AM, Valerii Hiora wrote:
> Hi,
>
> So finally Rust can cross-compile for iOS
Rust tasks do not support being killed at arbitrary points. You'll
have to arrange ahead of time for a "please die" message to be sent a
long a channel, or a similar scheme for transmitting this information.
On Wed, Jun 4, 2014 at 9:33 AM, Aravinda VK wrote:
> Hi,
>
> I am trying different altern
> Sorry for the brevity, I'm writing this from a phone and I haven't thought of
> this issue very thoroughly.
You appear to dislike one of the most fundamental features of Rust, so
I would encourage you to think through ideas such as this before
hastily posting to the mailing list.
The current i
The test runner captures stdout by default and prints it at the end of
the test run, but only if the test failed. This is intended to turn
down the noise of successful tests, especially the failing ones.
If you pass the --nocapture option to the test binary, it will disable
this behavior and print
> Waking up on timeout is hardly a good decision. Let's think about
> thousands of connections, each waking up at a reasonable timeouts
> (sometimes between 100 ms to 1 sec for my taste). The close_read is a
> hack that doesn't work for many cases (listening sockets, pipes, SCTP
> sockets, etc.)
>
There is no way to generically wake up or kill a task, it must be
arranged via some other means for the task to wake up. For TCP
connections, you can use the close_read() method or the
set_read_timeout() methods. In 0.10, this was not implemented (we
recommend you use master).
On Thu, May 15, 2014
Rust doesn't support life-before-main, which is basically what this
ends up entailing. What you've done already is likely what you'll want
to keep doing, which is explicitly chaining control flow through the
startup process.
On Thu, May 15, 2014 at 1:11 PM, Noah Watkins wrote:
> I'd like to put t
The equivalent of a function pointer in C is the bare fn type in rust. For
example, you could write your binding as:
// C code
int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n,
void(*)(void*));
// Rust definition
fn sqlite3_bind_text(stmt: *mut sqlite3_
The ~int type has since moved to Box, which will one day be a
library type with Deref implemented on it (currently it is implemented
by the compiler). Regardless, there's no need to implement the Deref
trait for the type today, the compiler already takes care of it.
For example, your code will com
While not currently possible, we plan on accommodating use cases such
as this through first-class allocators via type parameters. You'll be
able to specify your own allocator an standard library routines that
allocate memory.
Your other option currently is to link to libcore (which doesn't
provide
morestack, used
>> implicitly).
>>
>> I have the same problem with ISRs that re defined in libzinc. For now, I
>> make trampolines in the app code:
>>
>> #[no_mangle]
>> #[inline(never)]
>> #[no_split_stack]
>> pub unsafe fn task_schedule
In an rlib, all publicly reachable symbols will be exported from the
object, for example:
mod foo { pub static BAR: int = 3; }
That symbol is not exported because BAR is not reachable from the outside world.
pub use foo::BAR;
mod foo { pub static BAR: int = 3; }
This time, BAR will
Oddly enough, that was the first thing I jumped to as well! I think
that type inference like that doesn't drive method selection, which is
why it ended up not working out.
On Wed, Apr 30, 2014 at 3:54 AM, Michael Neumann wrote:
>
>
> Am 29.04.2014 22:51, schrieb Alex Crichton:
&
The by_ref() method exists on both the Reader and the Writer trait,
and you're working with a stream which implements both Reader and
Writer (hence the confusion by the compiler).
You could work around it with something like:
fn rdr<'a, T: Reader>(t: &'a mut T) -> RefReader<'a, T> {
t
This used to be present for the JIT support that the old rusti
provided, but the internal support for this has been removed. You may
be able to resurrect it outside the compiler with these LLVM apis, but
it may also require exposing more LLVM details from the compiler
itself.
There is currently no
thread. Is there any reason, why it's not a function?
> Any objections if I do some refactoring and make it a function? For a simple
> case that could be a weak symbol that returns a constant.
>
>
> On Tue, Apr 22, 2014 at 9:00 AM, Alex Crichton wrote:
>>
>> I agree wi
e a better look into what's going wrong on my side.
>> I'll see what I can do with that.
>>
>>
>> On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton wrote:
>>>
>>> The split stack patches for ARM were recently upstreamed, and they
>>> were mod
Welcome Aaron! I'm so excited to have you with us!
On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson wrote:
> Hey there, Rusticators,
>
> Grand news! Starting today Aaron Turon is joining the Rust team. Aaron did
> his PhD thesis on concurrency at Northeastern University, where he published
> widel
> Refcounting is, of course, unsuitable for objects with circular links and I’m
> going to have plenty of them.
You may be interested in the downgrade() method on Rc/Arc along with
the Weak pointers (they allow cycles, but also allow for destruction).
> So I’m thinking about adding per-task aren
The split stack patches for ARM were recently upstreamed, and they
were modified when being upstreamed as well. Primarily the location of
the split stack is no longer at a magic address for thumb, but rather
it uses the same instruction as ARM (some thumb processors do indeed
have the coprocessor).
> How do I manually implement "clone()" for Structs/Enums with lifetime
> parameters (e.g. for struct below)?
>
> ---
> struct Cls<'a,T> {
> x:&'a T
> }
impl<'a, T: Clone> Clone for Cls<'a, T> {
fn clone(&self) -> Cls<'a, T> {
Cls
The ~Any type has a special implementation of Show:
https://github.com/mozilla/rust/blob/master/src/libstd/any.rs#L151-L155
I believe it was primarily used in failure messages originally (you
can fail a task with ~Any)
On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang wrote:
> It current can compile
> unsafe { h.add(); }
>
> handles.insert(h.id(), h);
This is why the add method is unsafe: "This method is unsafe because
it requires that the Handle is not moved while it is added to the
Select set."
You're moving the handle after it's been added, which later will cause
a segfault.
_
Greetings Rustlers!
Projects such as cargo and Servo have recently expressed interest in having a
"breaking changes" changelog as part of the rust repository. It's often
difficult for those not closely tied to the compiler itself to keep up with all
the changes that are getting made. Additionally,
Your BaseImpl enum isn't necessarily Send because it contains a trait
object (~Base). The typechecker doesn't know what type is behind this
trait object, so it doesn't know whether it's send or not. To make the
BaseImpl type Send again, you can change the definition to:
enum BaseImpl {
As you've discovered in bug #13325, dealing with external constants in
static expressions is sometimes a little tricky. I would avoid casting
for now (as happens in the bug) in favor of stronger types. For
example, this compiles and runs for me:
extern {
fn foo();
fn bar();
first reexport.
* search works across crates that have been rendered to the same output
directory.
Contributors to Rust 0.10
Adrien Tétar
Alan Andrade
Alex Crichton
Alex Whitney
a_m0d
Andre Arko
Andrew Chin
aochagavia
Arcterus
Axel Viala
aydin.kim
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely remove many uses of
~[T] throughout the standard distribution. I'd like to take some
Greeting Rustlers!
Our lovely automation has recently prepared an 0.10 release candidate recently.
I've tested them slightly, and if you'd like to also give them a shot all the
links are included at the end of this message. Remember that this is not a
signed release yet, we've only got checksums f
gt;> >>> U STACK_LIMIT
>> >>> U _GLOBAL_OFFSET_TABLE_
>> >>> D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E
>> >>> 0008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E
>> >>> r _ZN2hw12GPIO_DIR_REG20hb0b70c14
You should be able to assemble standalone objects for any triple
through rustc itself, you'll likely have to specify a different linker
or assembler though:
rustc foo.rs --target arm-non-linux-gnueabi \
-C linker=arm-non-linux-gnueabi-ld \
-C ar=arm-non-linux-gnueabi-ar
As you
I would recommend using io::process with the detach option set to true
rather than invoking fork(). The green runtime is not fork-safe, and
at this time we're not guaranteeing that the native runtime is
fork-safe.
On Mon, Mar 17, 2014 at 4:59 AM, John Mija wrote:
> Is possible to fork/daemonize i
> I was working from the assumption that the initializers of non-mut statics
> are checked to ensure they do not contain values of non-Freeze types, nor
> destructors. Does the new plan also involve lifting this restriction? (From
> the below it seems like it does.)
Yes, by disallowing taking the
> Can someone explain why this is necessary?
>
> static FOO: Option> = None;
> let foo = &FOO;
Implementation-wise, FOO is placed into read-only memory in the
executable. This is done mainly for optimization purposes for LLVM.
Something like
static NUM_BITS: uint = 32;
should act lik
Right now #[link] only takes library names (it gets passed through as
a -l flag).
It doesn't seem much more brittle to use -C link-args than to have
absolute paths, so you may wish to explore that route.
On Wed, Mar 5, 2014 at 1:12 AM, Doug wrote:
> Hey~
>
> I've been trying to hook rust up the
You can use the prototype through `std::comm::Select` for now, but the
macro is not currently exported. See
https://github.com/mozilla/rust/issues/12044 for more information.
On Mon, Feb 24, 2014 at 10:59 PM, Frank Huang wrote:
> Hi everyone,
>
> Here with a novice question. I'm trying to use the
Greetings Rustafarians!
As of a few minutes ago, along with the merging of #12437, I would
like to inform everyone that we're now going to be building all Pull
Requests on Travis CI [1]. Travis is a continuous integration system
which integrates very well with Github and makes it fairly easy to ru
This feature was removed from the language in
https://github.com/mozilla/rust/pull/12244. The as_slice() method will
continue to work for now.
On Thu, Feb 20, 2014 at 4:53 PM, Michael Dagitses wrote:
> The following no longer works:
> let file = match std::os::args() {
> [_prog, f] => f,
> _
> Currently, all patches are being tested after they are approved. However, I
> think it would be of great benefit for contributors - and reviewers - to
> test patches before and after they're approved.
I would personally love to explore using Travis-CI for this. I think
this is almost exactly wha
> Does that include ABI compatibility?
For now, this is going to be tough to provide because of compiler bugs
sadly (see #10208 and #10207). ABI stability is a broad topic which
encompasses symbol names, whether the function is generic or not,
implementation of a generic function, etc. For now, I
d use the rust-llvm-2014-02-11 branch as the base for my PR?
>
> Svetoslav.
>
>
> -Original Message-
> From: alexc...@gmail.com [mailto:alexc...@gmail.com] On Behalf Of Alex
> Crichton
> Sent: Sunday, February 16, 2014 1:16 AM
> To: Svetoslav Neykov
> Cc: rus
For LLVM patches, we prefer if you have first attempted to upstream
the patch with LLVM before we push it to our local fork. This normally
entails emailing the llvm-commits mailing list. Once this upstream
attempt has been made, you can open a PR against the rust-lang/llvm
repo on github.
This loo
You'll always need a concrete type in order to get the trait method
for that type. Something like this may work for you though:
trait A {
fn foo(Self);
}
impl A for int { fn foo(a: int) {} }
fn main() {
let f: fn(int) = A::foo;
}
On Fri, Feb 14, 2014 at 2:14 PM, Tommy M. McGuire wrote:
wrote:
> Targetting ARM hard float, v7 CPU.
>
> Any ideas how to go about addressing this?
> --
> From My Tiny Glowing Screen
>
>
> On Fri, Feb 14, 2014 at 10:20 AM, Alex Crichton wrote:
>>
>> Are you targeting a platform other than x86? I recently added support
>> f
Are you targeting a platform other than x86? I recently added support
for 64-bit atomics on all platforms, and without the right cpu or
target feature set LLVM will lower them to intrinsic calls, and it's
possible that you're missing an intrinsic somewhere.
On Fri, Feb 14, 2014 at 9:48 AM, Ian Dan
Can you supply the output of `rustc -v`? The snippet complies ok for
me off master.
On Thu, Feb 13, 2014 at 8:17 AM, Liigo Zhuang wrote:
> I compiled the lasted rustc from source yesterday.
>
> 2014年2月13日 下午8:17于 "Alex Crichton" 写道：
>
>> What version of the compiler a
For reference, this topic was discussed last August as well:
https://mail.mozilla.org/pipermail/rust-dev/2013-August/005113.html
On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin wrote:
> Hi,
>
> The Rust documentation currently makes iterators behavior undefined after
> .next() has returned None onc
What version of the compiler are you using? The clone-able Chan only
very recently landed, so you'll need a very up-to-date compiler to get
the change.
On Thu, Feb 13, 2014 at 6:12 AM, Liigo Zhuang wrote:
> Hi Rusties,
>
> When try to compile tmp.rs, I got the error:
>
> ```
> tmp.rs:8:10: 8:19 e
This problem has been fixed on master, so I would recommend using
master or uninstalling LLVM temporarily from the system (a
non-standard gcc in the path may also mess with compilation)
On Sun, Feb 9, 2014 at 1:15 PM, Martin Koch wrote:
> Hi List
>
> I'm trying to get rust to compile, but I'm app
triggers a flush on stdout and stderr to
> avoid this uncomfortable situation.
>
> I suppose it would not be took difficult to incorporate this in Rust.
>
> -- Matthieu.
>
>>
>>
>>
>> On Sun, Feb 9, 2014 at 2:40 AM, Patrick Walton
>> wrote:
>
We do indeed want to make common tasks like this fairly lightweight,
but we also strive to require that the program handle possible error
cases. Currently, the code you have shows well what one would expect
when reading a line of input. On today's master, you might be able to
shorten it slightly to
Some of you may have already seen GitHub's new State of the Octoverse
2013 at http://octoverse.github.com/
I'd just like to point out that the rust repository closed the second
most number of issues (6408) on all of GitHub. Just to reiterate, out
of the millions of repositories on GitHub, we close
// Do something
> }
> Err(io_error) => match io_error.kind {
> EndOfFile => {
> // Do something for EOF
> }
> _ => return Err(io_error)
> }
> }
>
> -Palmer Cox
>
>
>
> On Mon, Feb 3, 2014 at 9:19 PM,
Welcome Nick!
I can't wait to see that 1.0 issue count go down!
On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson wrote:
> Hi Rusties,
>
> I'm just thrilled to announce today that Nick Cameron (nrc) has joined
> Mozilla's Rust team full-time. Nick has a PhD in programming language theory
> from Imp
> By returning a Result from all function calls, it's not much cleaner
> to handle errors
Oops, wrong word there, I meant to indicate that it *is* much cleaner
to handle errors with Result rather than conditions.
___
Rust-dev mailing list
Rust-dev@mozill
Greetings Rustaceans!
Upon updating your nightly builds tonight some of you may realize that
all I/O code will fail to compile. Fear not, this simply means that
#11946 has landed! The summary of this change is the same as its
title, "remove io::io_error". This is quite a far-reaching change,
despi
Our discussion in a recent meeting concluded that statics will not be
allowed to contain types with destructors, and you also won't be able
to move out of static items:
https://github.com/mozilla/rust/issues/10577#issuecomment-32294407
On Tue, Jan 28, 2014 at 3:34 PM, Kevin Ballard wrote:
> At f
> Shared memory is already far more solid and less experimental than the
> existing concurrency and I/O support.
> Rust is making a lot of semantic sacrifices for the sake of
> performance. I see most of it as being under the assumption that it
> will eventually perform well rather than being base
You'll want to do destructuring assignment here. This means that you
take ownership of all fields in parallel:
fn into_test2(self) -> Test2 {
let Test1 { a, b } = self;
Test2 {
c: a,
d: b as f64
}
}
On Sun, Jan 26, 2014 at 9:32 AM, Vladimir
Rust has the idea of "implicit copyability", a property of a type
formalized by the Pod trait. An implicitly copyable type is either a
primitive, or a structure/enum which is built from implicitly copyable
types (plus some extra rules in play here).
When you add a destructor (implementation of the
> What's the reason ~T not coerced to &T the same way as in the main()
> function and borrow3 -- ie. why isn't it automatically converted to &**v as
> it is in these cases? The conversion is identical, no? The inability in
> this particular context seems rather arbitrary.
Sadly this is correct. R
> fn borrow1<'a>(&'a self) -> &'a int {
> match (self) {
> // error: mismatched types: expected `&'a int` but found `~int`
> // (expected &-ptr but found ~-ptr)
> &Foo(ref v) => *v
> }
> }
This doesn't work because the local variable v ha
> Any way to prevent this, so that only I am allowed to create FieldDef
> structs but can still return references to them in my public API?
You'll want something like:
pub struct FieldDef {
priv field: int,
}
That way everyone can name your struct, but no one other than you can
construct it
>> The problem with this is that it requires that the *owner* of a type
>> have a *mutable slot*, and you cannot prevent owners from declaring
>> their slots as mutable. In the example you gave, you could write "let
>> mut var2 = Box { x: 2 }" and it would compile, there's nothing
>> preventing usa
> This is the part that I don't follow; why can't I just mark
> my mutable-only methods as taking a mutable self?
The problem with this is that it requires that the *owner* of a type
have a *mutable slot*, and you cannot prevent owners from declaring
their slots as mutable. In the example you gave
> Hi Rust experts,
How flattering!
> This seems like a great match for Rust, because an object could be
> created as "mut" and local to a single task, but then "become" non-mut
> and be sharable between tasks once frozen. And the refcounting scheme
> sounds like a great match for the Arc model.
> 1. I miss a search functionality on the mailing list. Am i just blind, or do
> i have to
> use google with the "site:" option?
The mailing list we use is pretty standard, and it's
archived/searchable on other mirrors (gmane I think mirrors our
mailing list)
> 2. I'm used to curly braces, but ev
The snapshots themselves are all "static binaries" in the sense that
they have no dynamic rust dependencies and only the "necessary" system
dependencies. Rustc does not generate 0-dependency static binaries
right now that depend on libstd (as that would involve rewriting libc
and writing a syscall
very impressive. Now we've got nearly complete and
>> reasonably fast I/O, fast message passing, a scheduler-agnostic standard
>> library, and very soon an embeddable runtime and a standard library that
>> can be used in almost any environment. After years of iteration I'
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no longer has
any scheduling baked into it, but rather it's refactored out into two libraries.
This means that if you want a 1:1 program, you can jettison all M:N support with
just a few `extern mod` statements
In the past we have explicitly attempted to drop as many suffixes as
possible (see #8090). This is a little bit of a tricky topic, and to
me it depends on how you name the iterator. To me, iter::Map and
container::Map are clearly different if they are named that way. If
they are imported and then n
> 1. Is doing part (b) necessary? That is, does LLVM's optimization
> already eliminate unused code?
I don't believe that it is from a final binary point of view.
Unreachable functions will be flagged as internal, and LLVM can do
whatever it wants with internal symbols. I would imagine that it wou
Additionally, we discussed this today at our weekly meeting, and the
minutes can be found here:
https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-19#autoderef
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-
Hello rust-dev!
Everyone's had their fair share of issues with autoref and autoderef,
and it's worth considering removing certain portions of it from the
compiler. The discussion around this has been rooted in the past, but
has recently been brought up as part of
https://github.com/mozilla/rust/is
>> * #[link(...)] becomes the new method of specifying linkage semantics on
>> extern
>> blocks, and it may be used similarly to link_args today
>
> I'd kind of like for this to be available at the crate level too since most
> libraries don't use OS X two-level namespaces and it's more convie
Rust’s old fmt! syntax also used % instead of {}. The reason for the switch was
to primarily support compatibility with an internationalization-style scheme of
string formatting. The main benefit of {} of % is that you can nest {} inside
of another format, whereas with % you’re limited to just o
t;
> On Fri, Nov 15, 2013 at 12:09 AM, Alex Crichton wrote:
>>
>> I've been thinking about static linking recently, along with a little bit
>> of
>> linking in general, and I wanted to see what others thought.
>>
>> # The Goal
>>
>> Primar
>> To this end, I mainly
>> point out that rust should roll in local native static libraries, and
>> just live with global native dynamic libraries.
>
> How does rustc know the difference? Because the "local native" libraries
> are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?
>> Hm, I suppose I should re-phrase. Rust's linkage model should not
>> attempt to lift dependence on global native libraries. These global
>> libraries (like libm and librt on linux) should be assumed to be
>> everywhere. Our result artifacts must always be linked against them
>> (if their functio
>> Primarily, I believe that if desired, rustc should be able to generate an
>> executable or dynamic library with no dependence on any rust libraries. This
>> includes things like librustrt and libextra. Rust shouldn't be striving to
>> lift
>> dependence on system libraries, that'll come at late
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries. Th
1 - 100 of 138 matches
Mail list logo
