Use the `span` fields in `PathSegment` and `TyParam` instead.
(Note that since it processes `ast::Path` not a qualified path (`hir::QPath` / `ast::QSelf`), UFCS path will be flattened: `<Foo as a::b::c::Trait>::D::E::F::g` will be seen as `a::b::c::Trait::D::E::F::g`.)
bors [Mon, 14 Aug 2017 14:15:06 +0000 (14:15 +0000)]
Auto merge of #43740 - michaelwoerister:local-id-in-typecktables, r=arielb1
Use hir::ItemLocalId as keys in TypeckTables.
This PR makes `TypeckTables` use `ItemLocalId` instead of `NodeId` as key. This is needed for incremental compilation -- for stable hashing and for being able to persist and reload these tables. The PR implements the most important part of https://github.com/rust-lang/rust/issues/40303.
Some notes on the implementation:
* The PR adds the `HirId` to HIR nodes where needed (`Expr`, `Local`, `Block`, `Pat`) which obviates the need to store a `NodeId -> HirId` mapping in crate metadata. Thanks @eddyb for the suggestion! In the future the `HirId` should completely replace the `NodeId` in HIR nodes.
* Before something is read or stored in one of the various `TypeckTables` subtables, the entry's key is validated via the new `TypeckTables::validate_hir_id()` method. This makes sure that we are not mixing information from different items in a single table.
That last part could be made a bit nicer by either (a) new-typing the table-key and making `validate_hir_id()` the only way to convert a `HirId` to the new-typed key, or (b) just encapsulate sub-table access a little better. This PR, however, contents itself with not making things significantly worse.
Also, there's quite a bit of switching around between `NodeId`, `HirId`, and `DefIndex`. These conversions are cheap except for `HirId -> NodeId`, so if the valued reviewer finds such an instance in a performance critical place, please let me know.
Ideally we convert more and more code from `NodeId` to `HirId` in the future so that there are no more `NodeId`s after HIR lowering anywhere. Then the amount of switching should be minimal again.
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
bors [Sun, 13 Aug 2017 23:33:18 +0000 (23:33 +0000)]
Auto merge of #43836 - taleks:issue-39827, r=arielb1
Fix for issue #39827
*Cause of the issue*
While preparing for `trans_intrinsic_call()` invoke arguments are processed with `trans_argument()` method which excludes zero-sized types from argument list (to be more correct - all arguments for which `ArgKind` is `Ignore` are filtered out). As result `volatile_store()` intrinsic gets one argument instead of expected address and value.
*How it is fixed*
Modification of the `trans_argument()` method may cause side effects, therefore change was implemented in `volatile_store()` intrinsic building code itself. Now it checks function signature and if it was specialised with zero-sized type, then emits `C_nil()` instead of accessing non-existing second argument.
bors [Sun, 13 Aug 2017 19:28:57 +0000 (19:28 +0000)]
Auto merge of #43815 - alexcrichton:optimize-alloc, r=sfackler
Optimize allocation paths in RawVec
Since the `Alloc` trait was introduced (https://github.com/rust-lang/rust/pull/42313) and it was integrated everywhere (https://github.com/rust-lang/rust/pull/42727) there's been some slowdowns and regressions that have slipped through. The intention of this PR is to try to tackle at least some of them, but they've been very difficult to quantify up to this point so it probably doesn't solve everything.
This PR primarily targets the `RawVec` type, specifically the `double` function. The codegen for this function is now much closer to what it was before #42313 landed as many runtime checks have been elided.
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
Guillaume Gomez [Sun, 13 Aug 2017 09:03:09 +0000 (11:03 +0200)]
Rollup merge of #43782 - nrc:include, r=GuillaumeGomez
Fix include! in doc tests
By making the path relative to the current file.
Fixes #43153
[breaking-change] - if you use `include!` inside a doc test, you'll need to change the path to be relative to the current file rather than relative to the working directory.
bors [Sun, 13 Aug 2017 05:24:49 +0000 (05:24 +0000)]
Auto merge of #43630 - Mark-Simulacrum:rustbuild-cleanups, r=alexcrichton
Rustbuild cleanups/fixes and improvements
Each commit is a standalone change, and can/should be reviewed separately.
This adds two new functionalities:
- `--target` and `--host` can be passed without changing config.toml, and we'll respect the users' wishes, instead of requiring that all possible targets are passed.
- Note that this means that `./x.py clean` won't be quite as wide-spread as before, since it limits itself to the configured hosts, not all hosts. This could be considered a feature as well.
- `ignore-git` field in `config.toml` which tells Rustbuild to not attempt to load git hashes from `.git`.
This is a precursor to eventual further simplification of the configuration system, but I want to get this merged first so that later work can be made in individual PRs.
bors [Sun, 13 Aug 2017 03:00:20 +0000 (03:00 +0000)]
Auto merge of #43348 - kennytm:fix-24658-doc-every-platform, r=alexcrichton
Expose all OS-specific modules in libstd doc.
1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.
2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.
3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.
Mark Simulacrum [Thu, 10 Aug 2017 05:12:35 +0000 (10:12 +0500)]
Clean tools after building libstd/libtest/librustc.
This fixes the bug we previously had where we'd build a libtest tool
after building a libstd tool and clear out the libstd tool. Since we
clear out all tools for a given stage on invocations of CleanTools after
lib{std, test, rustc} change, we need to make sure that all tools built
with that stage will be built after the clearing is done.
The fix contained here technically isn't perfect; there is still an edge
case of compiling a libstd tool, then compiling libtest, which will
clear out the libstd tool and it won't ever get rebuilt within that
session of rustbuild. This is where the caching system used today shows
it's problems -- in effect, all tools depend on a global counter of the
stage being cleared out. We can implement such a counter in a future
patch to ensure that tools are rebuilt as needed, but it is deemed
unlikely that it will be required in practice, since most if not all
tools are built after the relevant stage's std/test/rustc are built,
though this is only an opinion and hasn't been verified.
Mark Simulacrum [Thu, 3 Aug 2017 16:53:56 +0000 (10:53 -0600)]
Add ability to ignore git when building rust.
Some users of the build system change the git sha on every build due to
utilizing git to push changes to a remote server. This allows them to
simply configure that away instead of depending on custom patches to
rustbuild.
Mark Simulacrum [Sun, 30 Jul 2017 04:12:53 +0000 (22:12 -0600)]
Unify flags into config.
This introduces a slight change in behavior, where we unilaterally
respect the --host and --target parameters passed for all sanity
checking and runtime configuration.
bors [Sat, 12 Aug 2017 19:40:49 +0000 (19:40 +0000)]
Auto merge of #43724 - lukaramu:std-ops-docs, r=QuietMisdreavus
Improve std::ops docs
Fixes #29365. (This fixes all but one point from @steveklabnik's list, but that point was referring to examples of implementing range traits, but there are no range traits in std::ops.)
The main changes are quite a bit of copyediting, adding more "real" examples for some of the traits, incorporating some guidance from the API docs, more linking (cross-docs and to the book & reference), cleaning up examples, moving things around, and so on. Refer to the commit messages for more details.
Note: I decided to link to the second edition of the book since I think it's more appropriate now for the sections I linked, if this is not okay, please say so!
Alex Crichton [Fri, 11 Aug 2017 23:00:09 +0000 (16:00 -0700)]
std: Unsafe-away runtime checks in `Vec`
The `RawVec` type has a number of invariants that it upholds throughout its
execution, and as a result many of the runtime checks imposed by using `Layout`
in a "raw" fashion aren't actually necessary. For example a `RawVec`'s capacity
is intended to always match the layout which "fits" the allocation, so we don't
need any runtime checks when retrieving the current `Layout` for a vector.
Consequently, this adds a safe `current_layout` function which internally uses
the `from_size_align_unchecked` function.
Along the same lines we know that most construction of new layouts will not
overflow. All allocations in `RawVec` are kept below `isize::MAX` and valid
alignments are also kept low enough that we're guaranteed that `Layout` for a
doubled vector will never overflow and will always succeed construction.
Consequently a few locations can use `from_size_align_unchecked` in addition
when constructing the *new* layout to allocate (or reallocate), which allows for
eliding some more runtime checks.
Overall this should significant improve performance for an important function,
`RawVec::double`. This commit removes four runtime jumps before `__rust_realloc`
is called, as well as one after it's called.
lukaramu [Tue, 8 Aug 2017 12:34:37 +0000 (14:34 +0200)]
std::ops docs: incorporated changes suggested in review
* fixed link typos and copy-paster errors
* rewrote Fn* explanations
* `RHS = Self` -> `RHS` is `Self` (added that to all applicable places as
well)
* fixed up some links
* s/MutDeref/DerefMut
* removed remaining superfluous `fn main()`s
* fixed some minor phrasings and factual errors and inaccuracies
std::ops docs: Fix phrasing and factual errors/inaccuracies
bors [Sat, 12 Aug 2017 14:24:40 +0000 (14:24 +0000)]
Auto merge of #43823 - tchajed:fix-pr-link, r=frewsxcv
Update GitHub pull request documentation link
It looks like the GitHub documentation has been re-organized so that the "fork and pull" model isn't explained alongside the PR process in one convenient link any more.
bors [Sat, 12 Aug 2017 11:57:10 +0000 (11:57 +0000)]
Auto merge of #43746 - eddyb:sound-thread-local, r=alexcrichton
Check #[thread_local] statics correctly in the compiler.
Fixes #43733 by introducing `#[allow_internal_unsafe]` analogous to `#[allow_internal_unstable]`, for letting a macro expand to `unsafe` blocks and functions even in `#![forbid(unsafe_code)]` crates.
Fixes #17954 by not letting references to `#[thread_local]` statics escape the function they're taken in - we can't just use a magical lifetime because Rust has *lifetime parametrism*, so if we added the often-proposed `'thread` lifetime, we'd have no way to check it in generic code.
To avoid potential edge cases in the compiler, the lifetime is actually that of a temporary at the same position, i.e. `&TLS_STATIC` has the same lifetime `&non_const_fn()` would.
Referring to `#[thread_local]` `static`s at compile-time is banned now (as per PR discussion).
Additionally, to remove `unsafe impl Sync` from `std::thread::local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
Alexey Tarasov [Sat, 12 Aug 2017 08:43:59 +0000 (18:43 +1000)]
Follow up commit for the issue 39827
- updates documentation on volatile memory intrinsics, now the case of
zero-sized types is mentioned explicitly.
Volatile memory operations which doesn't affect memory at all are omitted
in LLVM backend, e.g. if number of elements is zero or type used in
generic specialisation is zero-sized, then LLVM intrinsic or related code
is not generated. This was not explicitly documented before in Rust
documentation and potentially could cause issues.
Alexey Tarasov [Sat, 12 Aug 2017 08:42:44 +0000 (18:42 +1000)]
Fixes issue 39827: ICE in volatile_store intrinsic
- adds handling of zero-sized types for volatile_store.
- adds type size checks and warnigns for other volatile intrinsics.
- adds a test to check warnings emitting.
Cause of the issue
While preparing for trans_intrinsic_call() invoke arguments are
processed with trans_argument() method which excludes zero-sized types
from argument list (to be more correct - all arguments for which
ArgKind is Ignore are filtered out). As result volatile_store() intrinsic
gets one argument instead of expected address and value.
How it is fixed
Modification of the trans_argument() method may cause side effects,
therefore change was implemented in volatile_store() intrinsic building
code itself. Now it checks function signature and if it was specialised
with zero-sized type, then emits C_nil() instead of accessing
non-existing second argument.
Additionally warnings are added for all volatile operations which are
specialised with zero-sized arguments. In fact, those operations are omitted
in LLVM backend if no memory affected at all, e.g. number of elements
is zero or type is zero-sized. This was not explicitly documented before
and could lead to potential issues if developer expects volatile behaviour,
but type has degraded to zero-sized.
bors [Sat, 12 Aug 2017 00:54:38 +0000 (00:54 +0000)]
Auto merge of #43772 - arielb1:nonfree-block, r=nagisa
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
Alex Crichton [Fri, 11 Aug 2017 22:58:26 +0000 (15:58 -0700)]
std: Tag `AllocErr` functions as `#[inline]`
None of these require a significant amount of code and using `#[inline]` will
allow constructors to get inlined, improving codegen at allocation callsites.
bors [Fri, 11 Aug 2017 22:23:10 +0000 (22:23 +0000)]
Auto merge of #43766 - michaelwoerister:trans-scheduler-touch-up, r=alexcrichton
Improve LLVM/trans scheduling a bit
Currently it's possible that the main thread is waiting on LLVM threads to finish work while its implicit token is going to waste. This PR let's the main thread take over, so one of the running LLVM threads can free its token earlier.
bors [Fri, 11 Aug 2017 19:43:44 +0000 (19:43 +0000)]
Auto merge of #43750 - tbu-:pr_fn_unreachable, r=sfackler
Put `intrinsics::unreachable` on a possible path to stabilization
Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
bors [Fri, 11 Aug 2017 13:04:59 +0000 (13:04 +0000)]
Auto merge of #43748 - RalfJung:mir-validate2, r=arielb1
AddValidation: handle Call terminators into blocks that have multiple incoming edges
The old code was just wrong: It would add validation on paths that don't even come from the call, and it would add multiple validations if multiple calls end return to the same block.
Make Definitions::find_node_for_hir_id() a linear search instead of a binary one.
Unfortunately, the NodeId->HirId array is not sorted. Since this search is only
done right before calling bug!(), let's not waste time allocating a faster lookup.
projects / rust.git / log