@nikomatsakis and I were talking about how the serializers were a bit too complicated. None of the users of With the `emit_option` and `read_option` functions, the serializers are now moving more high level. This patch series continues that trend. I've removed support for emitting specific string and vec types, and added support for emitting mapping types.
I believe this patch incorporates all expected syntax changes from extern
function reform (#3678). You can now write things like:
extern "<abi>" fn foo(s: S) -> T { ... }
extern "<abi>" mod { ... }
extern "<abi>" fn(S) -> T
The ABI for foreign functions is taken from this syntax (rather than from an
annotation). We support the full ABI specification I described on the mailing
list. The correct ABI is chosen based on the target architecture.
Calls by pointer to C functions are not yet supported, and the Rust type of
crust fns is still *u8.
Before it wouldn't warn about unused imports in the list if something in the list was used. These commits fix that case, add a test, and remove all unused imports in lists of imports throughout the compiler.
re bug that @nikomatsakis was hitting: when you define a `static` (old: `const`) containing a `&` or `&[]` expression, it will create temporaries (the underlying pointee) by creating a throwaway symbol for each temporary, each with _global_ linkage, and each named `"const"`. LLVM will helpfully rename multiple copies of this throwaway symbol to `"const1"` and `"const2"` and so forth in the _same_ library. But if you have _2 libraries_ -- say, libcore and librustc -- that both do this, the dynamic linker (at least on linux) will happily do horrible things like make the slice in one library point to the bytes of the vector from the other library. This is obviously a recipe for much hilarity and head-scratching.
The solution is to change the linkage to something else, internal or (in the case of this patch) _private_.
It will require a snapshot to integrate this into stage0 and thereby fix the problem / unblock patches that were hitting this in stage1.
Before, if anything in a list was used, the entire list was considered to be
used. This corrects this and also warns on a span of the actual unused import
instead of the entire list.
Impose a limit so that the typo suggester only shows reasonable
suggestions (i.e. don't suggest `args` when the error is `foobar`).
A tiny bit of progress on #2281.
Hey folks,
This patch series does some work on the json decoder, specifically with auto decoding of enums. Previously, we would take this code:
```
enum A {
B,
C(~str, uint)
}
```
and would encode a value of this enum to either `["B", []]` or `["C", ["D", 123]]`. I've changed this to `"B"` or `["C", "D", 123]`. This matches the style of the O'Caml json library [json-wheel](http://mjambon.com/json-wheel.html). I've added tests to make sure all this work.
In order to make this change, I added passing a `&[&str]` vec to `Decode::emit_enum_variant` so the json decoder can convert the name of a variant into it's position. I also changed the impl of `Encodable` for `Option<T>` to have the right upper casing.
I also did some work on the parser, which allows for `fn foo<T: ::cmp::Eq>() { ... }` statements (#5572), fixed the pretty printer properly expanding `debug!("...")` expressions, and removed `ast::expr_vstore_fixed`, which doesn't appear to be used anymore.
the types. Initially I thought it would be necessary to thread this data
through not only the AST but the types themselves, but then I remembered that
the pretty printer only cares about the AST. Regardless, I have elected to
leave the changes to the types intact since they will eventually be needed. I
left a few FIXMEs where it didn't seem worth finishing up since the code wasn't
crucial yet.
Because the json::Decoder uses the string variant name, we need a
way to correlate the string to the enum index. This passes in a
static &[&str] to read_enum_variant, which allows the json::Decoder
to know which branch it's trying to process.
Various FIXME comments added around to denote copies which when removed cause
the compiler to segfault at some point before stage2. None of these copies
should even be necessary.
- Most functions that used to return `~[~str]` for a list of substrings got turned into iterators over `&str` slices
- Some cleanup of apis, docs and code layout
and from typeck, which is verboten. We are supposed to write inference results
into the FnCtxt and then these get copied over in writeback. Add assertions
that no inference by-products are added to this table.
Fixes#3888Fixes#4036Fixes#4492
Kills some warnings, and implements str::each_char_reverse so that it actually iterates. The test case wasn't detecting a failure, since the loop body was never executed.
`let v = [24, ..1000];` now more or less emits the same IR as:
```Rust
let mut i = 0;
while i < 1000 {
v[i] = 24;
i += 1;
}
```
LLVM will still turn it into a memset if possible with optimization on.
The reasoning for doing it this way is that it's much easier to transition method-by-method to the `Map` API than trying to do the migration all at once.
I found an issue unrelated to my changes in one of the run-fail tests - if it uses `LinearMap`, it still fails but exits with 0. I xfailed it for now and opened [an issue](https://github.com/mozilla/rust/issues/5512), because it's not caused by these changes.
r? @nikomatsakis The typechecker previously passed around a boolean return flag to
indicate whether it saw something with type _|_ (that is, something
it knows at compile-time will definitely diverge) and also had some
manual checks for the `ty_err` pseudo-type that represents a previous
type error. This was because the typing rules implemented by the
typechecker didn't properly propagate _|_ and ty_err. I fixed it.
This also required changing expected error messages in a few tests,
as now we're printing out fewer derived errors -- in fact, at this
point we should print out no derived errors, so report any that
you see (ones that include "[type error]") as bugs.
A slice now always refers to something that returns an borrowed pointer, views don't exist anymore. If you want to have an explictit copy of a slice, use `to_owned()`
The typechecker previously passed around a boolean return flag to
indicate whether it saw something with type _|_ (that is, something
it knows at compile-time will definitely diverge) and also had some
manual checks for the `ty_err` pseudo-type that represents a previous
type error. This was because the typing rules implemented by the
typechecker didn't properly propagate _|_ and ty_err. I fixed it.
This also required changing expected error messages in a few tests,
as now we're printing out fewer derived errors -- in fact, at this
point we should print out no derived errors, so report any that
you see (ones that include "[type error]") as bugs.
Removes a lot of instances of `/*bad*/ copy` throughout libsyntax/librustc. On the plus side, this shaves about 2s off of the runtime when compiling `librustc` with optimizations.
Ideally I would have run a profiler to figure out which copies are the most critical to remove, but in reality there was a liberal amount of `git grep`s along with some spot checking and removing the easy ones.
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
This is done in two steps:
First, we make foreign functions not consider modes at all. This is because previously ++ mode was the only way to pass structs to foreign functions and so forth. We also add a lint mode warning if you use `&&` mode in a foreign function, since the semantics of that change (it used to pass a pointer to the C function, now it doesn't).
Then, we remove by value and make it equivalent to `+` mode. At the same time, we stop parsing `-` mode and convert all uses of it to `+` mode (it was already being parsed to `+` mode anyhow).
This obsoletes pull request #5298.
r? @brson
adjusting a few foreign functions that were declared with by-ref
mode. This also allows us to remove by-val mode in the near future.
With copy mode, though, we have to be careful because Rust will implicitly pass
somethings by pointer but this may not be the C ABI rules. For example, rust
will pass a struct Foo as a Foo*. So I added some code into the adapters to
fix this (though the C ABI rules may put the pointer back, oh well).
This patch also includes a lint mode for the use of by-ref mode
in foreign functions as the semantics of this have changed.
Continuing #5140
For the sake of getting this merged I've disabled debuginfo tests on mac (where running gdb needs root). Please feel free to follow up with further improvements.
r? @graydon
This removes `log` from the language. Because we can't quite implement it as a syntax extension (probably need globals at the least) it simply renames the keyword to `__log` and hides it behind macros.
After this the only way to log is with `debug!`, `info!`, etc. I figure that if there is demand for `log!` we can add it back later.
I am not sure that we ever agreed on this course of action, though I *think* there is consensus that `log` shouldn't be a statement.
These changes make const translation use adjustments (autodereference, autoreference, bare-fn-to-closure), like normal code does, replacing some ad-hoc logic that wasn't always right.
As a convenient side-effect, explicit dereference (both of pointers and of newtypes) is also supported in const expressions.
There is also a “bonus fix” for a bug in the pretty-printer exposed by one of the added tests.
Struct and enum representations have some complicatedness that's no longer needed. Now that everything's in one place and has access to anything we'd want to know about the type, flatten some of that out. Slight changes to representations in some cases.
The only thing we really lose is that C-like enums with one variant and a
non-zero discriminant now take up space, but I do not think this is a
common usage. As previously noted, that was mostly there for
transitional compatibility with the pre-adt.rs codebase.
Out goes the extra layer of struct wrapping; the destructedness flag is
added to the end of the struct. This means that, if the struct
previously had alignment padding at the end, the flag will live there
instead of increasing the struct size.
Changes the ad-hoc closure adjustment into using adjustment info instead
of being separately driven from types, and likewise for autoderef.
Also takes care of autoref (the cases we should be seeing in consts,
at least, since we can't be doing method calls which would need the
ref-to-vec mode), which didn't quite work right previously.
However, "dereference" of a newtype isn't handled yet....
