This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.
cc #10049Closes#8774
This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.
cc #10049Closes#8774
Fully support multiple lifetime parameters on types and elsewhere, removing special treatment for `'self`. I am submitting this a touch early in that I plan to push a new commit with more tests specifically targeting types with multiple lifetime parameters -- but the current code bootstraps and passes `make check`.
Fixes#4846
This Fixes#10265 and paves the way for fixing #9543. It works by adding a 'package_id' attribute by default for library crates that don't specify it. This is necessary to use the 'extern mod foo = "bar"' form instead of 'extern mod foo(name="bar") (as per #9543), because the former adds a required package_id when trying to link with the bar crate. I added a simple test to ensure that the default package_id value is being generated, and also added an explicit package_id in the link attribute in all rust libs to avoid getting warnings about default package_id values when building rust.
I'm not sure this is something you're interested in, but I was playing around the Any trait a bit and I wanted to try it as a key in a HashMap. To do that, TypeId needs to implement IterBytes.
all the information it has at its disposal. Unfortunately this also
reveals that we need to improve the reporting heuristics further,
as sometimes the errors it chooses to emit seem somewhat mystifying
and are not related to the actual problem.
This code fits better in check because it is checking that the impl
matches the interface. This allows us to avoid the awkward constructions
that lazilly collect traits and so forth. It also permits us to make
use of the results of variance inference.
This rearranges the deriving code so that #[deriving] a trait on a field
that doesn't implement that trait will point to the field in question,
e.g.
struct NotEq; // doesn't implement Eq
#[deriving(Eq)]
struct Foo {
ok: int,
also_ok: ~str,
bad: NotEq // error points here.
}
Unfortunately, this means the error is disconnected from the `deriving`
itself but there's no current way to pass that information through to
rustc except via the spans, at the moment.
Fixes#7724.
This section desperately needs to be expanded, but removing the
misleading/incorrect information is a priority.
Managed vectors/strings are not covered, as they are feature-gated and
are only a micro-optimization to avoid double-indirection.
Closes#6882
