-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inform user where to give a type annotation after a call to collect #47982
Closed
csmoe
wants to merge
297
commits into
rust-lang:master
from
csmoe:give_type_annotation_after_collect
Closed
inform user where to give a type annotation after a call to collect #47982
csmoe
wants to merge
297
commits into
rust-lang:master
from
csmoe:give_type_annotation_after_collect
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
We use binaryen's linker to produce a wasm file (via s2wasm). The wasm writer has capabilities to export source maps. The produced source map contains references to the original file, that might require additional source map file processing to include / package original files with it.
is_unsafe_place only filters out statics in the rhs, not the lhs. Since it's possible to reach that 'Place::Static', we handle statics the same way as we do locals. Fixes rust-lang#47789
Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
Currently ', " and \ are escaped as \', \" and \\ respectively. This leads to confusing messages such as `error: unknown start of token: \\` when encountering a single backslash. Fix by emitting printable ASCII characters directly. This will still escape \r, \n, \t and Unicode characters. Fixes rust-lang#47902
The `exchange_free` lang item is gone in favour of `box_free` [1]. Some warnings are also fixed by this commit. [1]: rust-lang@ca115dd
Otherwise we get random TySelfs there, which means operations on RETURN_PLACE end up breaking down badly.
Clearing out the infcx's region constraints after processing each type ends up interacting badly with normalizing associated types. This commit keeps all region constraints intact until the end of TypeLivenessGenerator.add_drop_live_constraint, ensuring that normalized types are able to re-use existing inference variables. Fixes rust-lang#47589
Introduced in rust-lang#47828 to help track down some bugs, it landed a bit hastily so this is intended on cleaning it up a bit.
…k-Simulacrum Update the dlmalloc submodule A bug was recently fixed in dlmalloc which meant that released memory to the system accidentally wasn't getting reused, causing programs to be far slower than they should be!
…chton fix typos in src/{bootstrap,ci,etc,lib{backtrace,core,fmt_macros}} via codespell
…kennytm Explain unusual debugging code in librustc Introduced in rust-lang#47828 to help track down some bugs, it landed a bit hastily so this is intended on cleaning it up a bit.
…oc, r=frewsxcv Document the behaviour of infinite iterators on potentially-computable methods It’s not entirely clear from the current documentation what behaviour calling a method such as `min` on an infinite iterator like `RangeFrom` is. One might expect this to terminate, but in fact, for infinite iterators, `min` is always nonterminating (at least in the standard library). This adds a quick note about this behaviour for clarification.
Rollup of 20 pull requests - Successful merges: rust-lang#47790, rust-lang#47835, rust-lang#47854, rust-lang#48015, rust-lang#48047, rust-lang#48051, rust-lang#48058, rust-lang#48059, rust-lang#48064, rust-lang#48078, rust-lang#48080, rust-lang#48086, rust-lang#48098, rust-lang#48101, rust-lang#48107, rust-lang#48100, rust-lang#48085, rust-lang#48120, rust-lang#48124, rust-lang#47547 - Failed merges:
Update RELEASES.md for 1.24.0 [rendered](https://github.com/Aaronepower/rust/blob/master/RELEASES.md)
…tsakis rustc_mir: insert a dummy access to places being matched on, when building MIR. Fixes rust-lang#47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`. r? @nikomatsakis
Emit data::Impl in save-analysis As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis. A number of questions are outstanding: - [x] A few `???` around row 356. We need to discuss what goes here, if anything. - [ ] ~~Deriving `id` for impl using hashing. Is this going to clash with rustc defids?~~ - [ ] ~~Deriving `id` for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?~~ - [x] Need a new rls-data with an `id` field in `Impl` struct. - [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~
Fix oversized loads on x86_64 SysV FFI calls The x86_64 SysV ABI should use exact sizes for small structs passed in registers, i.e. a struct that occupies 3 bytes should use an i24, instead of the i32 it currently uses. Refs rust-lang#45543
…akis Implement `?` macro repetition See rust-lang/rfcs#2298 (with disposition merge)
This should save a lot of space on musl test cases (whose standard library are linked statically).
This isn't a perfect heuristic, but since the amount of run-fail tests is far lower than run-pass tests for now, it should be sufficient to ensure that we don't run into CI limits. This makes it possible to run the test binary manually (e.g., under gdb/lldb) if it failed to attempt to find out why.
…-Simulacrum Compiletest: delete the compiled program once its test is done. Reduces CI disk usage which prevents rust-lang#48118 from succeeding.
Add `-Zteach` documentation Add extra inline documentation to E0019, E0016, E0013, E0396, E0017, E0018, E0010, E0022, E0030, E0029, E0033, E0026 and E0027. Follow up to rust-lang#47652.
Hi @csmoe, and thanks for the PR! We haven't heard from you in a while, could you address #47982 (comment)? Thanks! |
…kfelix Optimized error reporting for recursive requirements rust-lang#47720 Fixes rust-lang#47720
…om/csmoe/rust into give_type_annotation_after_collect
…github.com/csmoe/rust into give_type_annotation_after_collect" This reverts commit 9a39471, reversing changes made to 6889c08.
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Feb 19, 2018
…tebank inform user where to give a type annotation should resolve rust-lang#47777 previous pull request rust-lang#47982 was closed because of a mistaken rebase. r? @estebank
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Feb 21, 2018
…tebank inform user where to give a type annotation should resolve rust-lang#47777 previous pull request rust-lang#47982 was closed because of a mistaken rebase. r? @estebank
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
should resolve #47777