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 new pass is run before type checking so that recursive items
are detected beforehand. This prevents going into an infinite
recursion during type checking when a recursive item is used in
an array type.
As a bonus, use `span_err` instead of `span_fatal` so multiple
errors can be reported.
Closes issue #17252
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.
When checking for an existing crate, compare against the `crate_metadata::name` field, which is the crate name which was requested during resolution, rather than the result of the `crate_metadata::name()` method, which is the crate name within the crate metadata, as these may not match when using the --extern option to `rustc`.
This fixes spurious "multiple crate version" warnings under the following scenario:
- The crate `foo`, is referenced multiple times
- `--extern foo=./path/to/libbar.rlib` is specified to rustc
- The internal crate name of `libbar.rlib` is not `foo`
The behavior surrounding `Context::should_match_name` and the comments in `loader.rs` both lead me to believe that this scenario is intended to work.
Fixes#17186
