This patch does not make many functional changes, but does a lot of restructuring towards the goals of #5527. This is the biggest patch, basically, that should enable most of the other patches in a relatively straightforward way.
Major changes:
- Do not track impls through trans, instead recompute as needed.
- Isolate trait matching code into its own module, carefully structure to distinguish various phases (selection vs confirmation vs fulfillment)
- Consider where clauses in their more general form
- Integrate checking of builtin bounds into the trait matching process, rather than doing it separately in kind.rs (important for opt-in builtin bounds)
What is not included:
- Where clauses are still not generalized. This should be a straightforward follow-up patch.
- Caching. I did not include much caching. I have plans for various kinds of caching we can do. Should be straightforward. Preliminary perf measurements suggested that this branch keeps compilation times roughly what they are.
- Method resolution. The initial algorithm I proposed for #5527 does not work as well as I hoped. I have a revised plan which is much more similar to what we do today.
- Deref vs deref-mut. The initial fix I had worked great for autoderef, but not for explicit deref.
- Permitting blanket impls to overlap with specific impls. Initial plan to consider all nested obligations before considering an impl to match caused many compilation errors. We have a revised plan but it is not implemented here, should be a relatively straightforward extension.
The wording is correct if you consider that two of these lines were extracted from the original example. It still tripped me up while reading, so i just removed any reference to the linecount.
I'm rotating in some CentOS 5.10 bots so we *actually* build on Linux 2.6.18
like we advertise doing so. Currently the snapshots are incompatible with CentOS
5.10 due to snapshots requiring glibc 2.6 and CentOS 5.10 having glibc 2.5.
It turns out that rustc only requires *one* symbol from glibc 2.6, which is
`futimens`. The rust distribution itself does not use this symbol, but LLVM
conditionally detects it and then uses it. This symbol isn't even called as part
of the compilation process, so we don't even need it!
The new snapshot was generated following these instructions [1]:
1. Download the current x86_64 linux snapshot and unpack it.
2. Open the rustc binary in a hex editor.
3. Change the linkage against glibc 2.6 from strong to *weak*
4. Write changes and re-run src/etc/make-snapshot.py
5. Upload new tarball to S3
On CentOS 5.10 a warning is printed each time the snapshot runs that the symbol
cannot be found (anyone with glibc 2.6+ does not have this warning printed). The
key part is that we can *bootstrap* on CentOS 5.10 at this point. The next
snapshot will be naturally compatible with glibc 2.3 (even older!) and will not
need to be manually edited.
[1]: http://jamesbond3142.no-ip.org/wiki/wiki.cgi/NewAppsOnOldGlibc
I'm rotating in some CentOS 5.10 bots so we *actually* build on Linux 2.6.18
like we advertise doing so. Currently the snapshots are incompatible with CentOS
5.10 due to snapshots requiring glibc 2.6 and CentOS 5.10 having glibc 2.5.
It turns out that rustc only requires *one* symbol from glibc 2.6, which is
`futimens`. The rust distribution itself does not use this symbol, but LLVM
conditionally detects it and then uses it. This symbol isn't even called as part
of the compilation process, so we don't even need it!
The new snapshot was generated following these instructions [1]:
1. Download the current x86_64 linux snapshot and unpack it.
2. Open the rustc binary in a hex editor.
3. Change the linkage against glibc 2.6 from strong to *weak*
4. Write changes and re-run src/etc/make-snapshot.py
5. Upload new tarball to S3
On CentOS 5.10 a warning is printed each time the snapshot runs that the symbol
cannot be found (anyone with glibc 2.6+ does not have this warning printed). The
key part is that we can *bootstrap* on CentOS 5.10 at this point. The next
snapshot will be naturally compatible with glibc 2.3 (even older!) and will not
need to be manually edited.
[1]: http://jamesbond3142.no-ip.org/wiki/wiki.cgi/NewAppsOnOldGlibc
The `StrInterner::clear()` method takes self immutably but can invalidate references returned by `StrInterner::get_ref`. Since `get_ref` is unused, just remove it.
Closes#17181
Sized deallocation makes it pointless to provide an address that never
overlaps with pointers returned by an allocator. Code can branch on the
capacity of the allocation instead of a comparison with this sentinel.
This improves the situation in #8859, and the remaining issues are only
from the logging API, which should be disabled by default in optimized
release builds anyway along with debug assertions. The remaining issues
are part of #17081.
Closes#8859
- Unify the "well-formedness" checking that typeck was already doing with what
was taking place in kind.
- Move requirements that things be sized into typeck.
- I left the checking on upvars in kind, though I think it should eventually be
refactored into regionck (which would perhaps be renamed).
This reflects a general plan to convert typeck so that it registers
obligations or other pending things for conditions it cannot check
eventually. This makes it easier to identify all the conditions that
apply to an AST expression, but can also influence inference in somec
cases (e.g., `Send` implies `'static`, so I already had to promote a lot
of the checking that `kind.rs` was doing into typeck, this branch just
continues the process).
I would like to map this information back to AST nodes, so that we can print remarks with spans, and so that remarks can be enabled on a per-function basis. Unfortunately, doing this would require a lot more code restructuring — for example, we currently throw away the AST map and lots of other information before LLVM optimizations run. So for the time being, we print the remarks with debug location strings from LLVM. There's a warning if you use `-C remark` without `--debuginfo`.
Fixes#17116.
This isn't ready to merge yet.
The 'containers and iterators' guide is basically just a collection of stuff that should be in the module definitions. So I'm moving the guide to just an 'iterators' guide, and moved the info that was there into the right places.
So, is this a good path forward, and is all of the information still correct?
This updates our build system to prefer `i686-w64-mingw32` as the 32-bit windows triple instead of `i686-pc-mingw32`. This is an interim step to make the build artifacts consistent until https://github.com/rust-lang/rust/issues/15717 is done.
Don't pass -fno-use-linker-plugin on OS X as clang does not accept it.
clang fails linking with:
```
error: linking with `cc` failed: exit code: 1
... arg list omitted...
note: clang: error: unknown argument: '-fno-use-linker-plugin' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
```
clang version:
```
$ clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.2.0
Thread model: posix
```
This is implemented using a new struct PartialVec which implements the proper
drop semantics in case the conversion is interrupted by an unwind.
For the old pull requests, see #15302, #16369.
This is important because the underlying allocator of the `Vec` passes that
information to the deallocator which needs the guarantee that it is the same
parameters that were also passed to the allocation function.
Replaces Gc<T> in the AST with a custom owned smart pointer, P<T>. Fixes#7929.
## Benefits
* **Identity** (affinity?): sharing AST nodes is bad for the various analysis passes (e.g. one could bypass borrowck with a shared `ExprAddrOf` node taking a mutable borrow), the only reason we haven't hit any serious issues with it is because of inefficient folding passes which will always deduplicate any such shared nodes. Even if we were to switch to an arena, this would still hold, i.e. we wouldn't just use `&'a T` in the AST, but rather an wrapper (`P<'a, T>`?).
* **Immutability**: `P<T>` disallows mutating its inner `T` (unless that contains an `Unsafe` interior, which won't happen in the AST), unlike `~T`.
* **Efficiency**: folding can reuse allocation space for `P<T>` and `Vec<T>`, the latter even when the input and output types differ (as it would be the case with arenas or an AST with type parameters to toggle macro support). Also, various algorithms have been changed from copying `Gc<T>` to using `&T` and iterators.
* **Maintainability**: there is another reason I didn't just replace `Gc<T>` with `~T`: `P<T>` provides a fixed interface (`Deref`, `and_then` and `map`) which can remain fully functional even if the implementation changes (using a special thread-local heap, for example). Moreover, switching to, e.g. `P<'a, T>` (for a contextual arena) is easy and mostly automated.
