- 31 7月, 2017 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 30 7月, 2017 16 次提交
-
-
由 Tobias Schottdorf 提交于
This PR kicks off the implementation of the [default binding modes RFC][1] by introducing the `pat_binding_modes` typeck table mentioned in the [mentoring instructions][2]. `pat_binding_modes` is populated in `librustc_typeck/check/_match.rs` and used wherever the HIR would be scraped prior to this PR. Unfortunately, one blemish, namely a two callers to `contains_explicit_ref_binding`, remains. This will likely have to be removed when the second part of [1], the `pat_adjustments` table, is tackled. Appropriate comments have been added. See #42640. [1]: https://github.com/rust-lang/rfcs/pull/2005 [2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089
-
由 bors 提交于
Rollup of 8 pull requests - Successful merges: #43409, #43501, #43509, #43512, #43513, #43536, #43544, #43549 - Failed merges:
-
由 Mark Simulacrum 提交于
rustbuild: Enable building LLVM I use this from time to time debugging LLVM builds, useful to have!
-
由 Mark Simulacrum 提交于
Update redox sys - Add JoinHandleExt - Split FL and FD for fcntl
-
由 Mark Simulacrum 提交于
Flag docker invocations as --privileged on CI When upgrading to LLVM 5.0 it was found that the leak sanitizer tests were failing with fatal errors, but they were passing locally when run. Turns out it looks like they may be using new ptrace-like syscalls so the docker container now needs `--privileged` when executing to complete the test.
-
由 Mark Simulacrum 提交于
std: Mark `Layout::repeat` as `#[inline]` This fixes an optimization regression by allowing LLVM to see through more functions. Closes #43272
-
由 Mark Simulacrum 提交于
erase types in the move-path abstract domain Leaving types unerased would lead to 2 types with a different "name" getting different move-paths, which would cause major brokenness (see e.g. #42903). This does not fix any *known* issue, but is required if we want to use abs_domain with non-erased regions (because the same can easily have different names). cc @RalfJung. r? @EddyB
-
由 Mark Simulacrum 提交于
rustdoc: add [src] links to associated functions inside an impl block While impl blocks currently have a `[src]` link to show the source for the impl block as a whole, individual methods inside that impl block do not. This can pose a problem for structs with a lot of methods, like many in libstd. This change adds little `[src]` links to individual methods that point directly to the function in the bundled source. fixes #12932 ![methods on HashMap, showing the new src links](https://user-images.githubusercontent.com/5217170/28686066-9e7a19de-72cf-11e7-8e6b-b7d60fa33032.png)
-
由 Mark Simulacrum 提交于
Add Span to ast::WhereClause This PR adds `Span` field to `ast::WhereClause`. The motivation here is to make rustfmt's life easier when recovering comments before and after where clause. r? @nrc
-
由 Mark Simulacrum 提交于
doc: make into_iter example more concise Also, remove dupe example
-
由 bors 提交于
Throw errors when doc comments are added where they're unused #42617
-
由 Guillaume Gomez 提交于
-
由 Alex Crichton 提交于
When upgrading to LLVM 5.0 it was found that the leak sanitizer tests were failing with fatal errors, but they were passing locally when run. Turns out it looks like they may be using new ptrace-like syscalls so the docker container now needs `--privileged` when executing to complete the test.
-
由 Alex Crichton 提交于
I use this from time to time debugging LLVM builds, useful to have!
-
由 bors 提交于
Changing E0623 error message - both anonymous lifetime regions Changing the error message to ``` error[E0623]: lifetime mismatch --> $DIR/ex3-both-anon-regions.rs:12:12 | 11 | fn foo(x: &mut Vec<&u8>, y: &u8) { | --- --- these references are not declared with the same lifetime... 12 | x.push(y); | ^ ...but data from `y` flows into `x` here error: aborting due to previous error ``` cc @nikomatsakis @aturon @jonathandturner r? @nikomatsakis
-
由 Alex Crichton 提交于
This fixes an optimization regression by allowing LLVM to see through more functions. Closes #43272
-
- 29 7月, 2017 15 次提交
-
-
由 Jeremy Soller 提交于
-
由 Ian Douglas Scott 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
rustbuild: Use Cargo's "target runner" This commit leverages a relatively new feature in Cargo to execute cross-compiled tests, the `target.$target.runner` configuration. We configure it through environment variables in rustbuild and this avoids the need for us to locate and run tests after-the-fact, instead relying on Cargo to do all that execution for us.
-
由 gaurikholkar 提交于
-
由 bors 提交于
rustbuild: Update cross-compilers for FreeBSD When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD cross compilers we're currently using are unable to build LLVM, failing with references to the function `std::to_string` claiming it doesn't exist. I don't actually know what this function is, but assuming that it was added in a more recent version of a C++ standard I've updated the gcc versions for the toolchains we're using. This made the error go away!
-
由 bors 提交于
rustbuild: Tweak how we cross-compile LLVM In preparation for upgrading to LLVM 5.0 it looks like we need to tweak how we cross compile LLVM slightly. It's using `CMAKE_SYSTEM_NAME` to infer whether to build libFuzzer which only works on some platforms, and then once we configure that it needs to apparently reach into the host build area to try to compile `llvm-config` as well. Once these are both configured, though, it looks like we can successfully cross-compile LLVM.
-
由 bors 提交于
More Altivec Intrinsics
-
由 Alex Crichton 提交于
This commit leverages a relatively new feature in Cargo to execute cross-compiled tests, the `target.$target.runner` configuration. We configure it through environment variables in rustbuild and this avoids the need for us to locate and run tests after-the-fact, instead relying on Cargo to do all that execution for us.
-
由 Alex Crichton 提交于
When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD cross compilers we're currently using are unable to build LLVM, failing with references to the function `std::to_string` claiming it doesn't exist. I don't actually know what this function is, but assuming that it was added in a more recent version of a C++ standard I've updated the gcc versions for the toolchains we're using. This made the error go away!
-
由 Alex Crichton 提交于
In preparation for upgrading to LLVM 5.0 it looks like we need to tweak how we cross compile LLVM slightly. It's using `CMAKE_SYSTEM_NAME` to infer whether to build libFuzzer which only works on some platforms, and then once we configure that it needs to apparently reach into the host build area to try to compile `llvm-config` as well. Once these are both configured, though, it looks like we can successfully cross-compile LLVM.
-
由 bors 提交于
Implement tokenization for some items in proc_macro This PR is a partial implementation of https://github.com/rust-lang/rust/issues/43081 targeted towards preserving span information in attribute-like procedural macros. Currently all attribute-like macros will lose span information with the input token stream if it's iterated over due to the inability of the compiler to losslessly tokenize an AST node. This PR takes a strategy of saving off a list of tokens in particular AST nodes to return a lossless tokenized version. There's a few limitations with this PR, however, so the old fallback remains in place.
-
由 Alex Crichton 提交于
This is then later used by `proc_macro` to generate a new `proc_macro::TokenTree` which preserves span information. Unfortunately this isn't a bullet-proof approach as it doesn't handle the case when there's still other attributes on the item, especially inner attributes. Despite this the intention here is to solve the primary use case for procedural attributes, attached to functions as outer attributes, likely bare. In this situation we should be able to now yield a lossless stream of tokens to preserve span information.
-
由 bors 提交于
improve case with both anonymous lifetime parameters #43269 This is a fix to #43269. Sample output message- ``` error[E0623]: lifetime mismatch --> $DIR/ex3-both-anon-regions.rs:12:12 | 11 | fn foo(x: &mut Vec<&u8>, y: &u8) { | --- --- these references must have the same lifetime 12 | x.push(y); | ^ data from `y` flows into `x` here error: aborting due to 2 previous errors ``` r? @nikomatsakis
-
- 28 7月, 2017 8 次提交
-
-
由 topecongiro 提交于
-
由 Alex Crichton 提交于
This test currently fails because the tokenization of an AST item during the expansion of a procedural macro attribute rounds-trips through strings, losing span information.
-
由 Alex Crichton 提交于
This partly resolves the `FIXME` located in `src/libproc_macro/lib.rs` when interpreting interpolated tokens. All instances of `ast::Item` which have a list of tokens attached to them now use that list of tokens to losslessly get converted into a `TokenTree` instead of going through stringification and losing span information. cc #43081
-
由 Alex Crichton 提交于
This commit adds a new field to the `Item` AST node in libsyntax to optionally contain the original token stream that the item itself was parsed from. This is currently `None` everywhere but is intended for use later with procedural macros.
-
由 Luca Barbato 提交于
The function should accept feature strings that old LLVM might not support. Simplify the code using the same approach used by LLVMRustPrintTargetFeatures. Dummify the function for non 4.0 LLVM and update the tests accordingly.
-
由 bors 提交于
Provide positional information when visiting ty, substs and closure_substs in MIR This will enable the region renumbering portion of #43234 (non-lexical lifetimes). @nikomatsakis's current plan [here](https://gist.github.com/nikomatsakis/dfc27b28cd024eb25054b52bb11082f2) shows that we need spans of the original code to create new region variables, e.g. `self.infcx.next_region_var(infer::MiscVariable(span))`. The current visitor impls did not pass positional information (`Location` in some, `Span` and `SourceInfo` for others) for all types. I did not expand this to all visits, just the ones necessary for the above-mentioned plan.
-
由 bors 提交于
Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str, *T, and [T]. No idea if these changes are reasonable - please feel free to suggest changes/rewrites. And these are some of my first real commits to any rust codebase - *don't* be gentle, and nitpick away, I need to learn! ;) ### Overview Embedding `.natvis` files into `.pdb`s allows MSVC (and potentially other debuggers) to automatically pick up the visualizers without having to do any additional configuration (other than to perhaps add the relevant .pdb paths to symbol search paths.) The native debug engine for MSVC parses the type names, making various C++ish assumptions about what they mean and adding various limitations to valid type names. `&str` cannot be matched against a visualizer, but if we emit `str&` instead, it'll be recognized as a reference to a `str`, solving the problem. `[T]` is similarly problematic, but emitting `slice<T>` instead works fine as it looks like a template. I've been unable to get e.g. `slice<u32>&` to match visualizers in VS2015u3, so I've gone with `str*` and `slice<u32>*` instead. ### Possible Issues * I'm not sure if `slice<T>` is a great mangling for `[T]` or if I should worry about name collisions. * I'm not sure if `linker.rs` is the right place to be enumerating natvis files. * I'm not sure if these type name mangling changes should actually be MSVC specific. I recall seeing gdb visualizer tests that might be broken if made more general? I'm hesitant to mess with them without a gdb install. But perhaps I'm just wracking up technical debt. Should I try `pacman -S mingw-w64-x86_64-gdb` and to make things consistent? * I haven't touched `const` / `mut` yet, and I'm worried MSVC might trip up on `mut` or their placement. * I may like terse oneliners too much. * I don't know if there's broader implications for messing with debug type names here. * I may have been mistaken about bellow test failures being ignorable / unrelated to this changelist. ### Test Failures on `x86_64-pc-windows-gnu` ``` ---- [debuginfo-gdb] debuginfo-gdb\associated-types.rs stdout ---- thread '[debuginfo-gdb] debuginfo-gdb\associated-types.rs' panicked at 'gdb not available but debuginfo gdb debuginfo test requested', src\tools\compiletest\src\runtest.rs:48:16 note: Run with `RUST_BACKTRACE=1` for a backtrace. [...identical panic causes omitted...] ---- [debuginfo-gdb] debuginfo-gdb\vec.rs stdout ---- thread '[debuginfo-gdb] debuginfo-gdb\vec.rs' panicked at 'gdb not available but debuginfo gdb debuginfo test requested', src\tools\compiletest\src\runtest.rs:48:16 ``` ### Relevant Issues * https://github.com/rust-lang/rust/issues/40460 Metaissue for Visual Studio debugging Rust * https://github.com/rust-lang/rust/issues/36503 Investigate natvis for improved msvc debugging * https://github.com/PistonDevelopers/VisualRust/issues/160 Debug visualization of Rust data structures ### Pretty Pictures ![Collapsed Watch Window](https://user-images.githubusercontent.com/75894/28180998-e44c7516-67bb-11e7-8b48-d4f9605973ae.png) ![Expanded Watch Window](https://user-images.githubusercontent.com/75894/28181000-e8da252e-67bb-11e7-96b8-d613310c04dc.png)
-
由 bors 提交于
rustc_const_eval: always require Substs and a ParamEnv. Fixes #43357 by tracking the `Substs` and `ParamEnv` for const-evaluation in generic contexts.
-