| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use per-span hygiene in a few other places in resolve
Prefer `rust_2015`/`rust_2018` helpers to comparing editions
|
|
|
|
|
|
Give each PathSegment a NodeId
Store a resolved def on hir::PathSegment
save-analysis: remove hacky, unnecessary code now that we have spans for every ident
dump data for prefix path segments
dump refs for path segments in save-analysis
Requires adding path segments to the hir map
Fix tests and rustdoc
save-analysis: handle missing field names
FIxes https://github.com/rust-lang-nursery/rls/issues/1031
rebasing and reviewer changes
Primarily refactoring `(Ident, Option<NodeId>)` to `Segment`
Fix tests and assertions; add some comments
more reviewer changes
|
|
macro paths
|
|
Flatten relative offset into directory path before adding inline
(mod x { ... }) module names to the current directory path.
Fix #55094
|
|
|
|
Remove redundant clone
|
|
fix typos in various places
|
|
Accept `Option<Box<$t:ty>>` in macro argument
Given the following code, compile successfuly:
```
macro_rules! test {
(
fn fun() -> Option<Box<$t:ty>>;
) => {
fn fun(x: $t) -> Option<Box<$t>>
{ Some(Box::new(x)) }
}
}
test! {
fn fun() -> Option<Box<i32>>;
}
```
Fix #25274.
|
|
Fix rustdoc and fulldeps tests
|
|
|
|
|
|
Stabilize impl_header_lifetime_elision in 2015
~~This is currently blocked on https://github.com/rust-lang/rust/issues/54902; it should be good after that~~
It's already stable in 2018; this finishes the stabilization.
FCP completed (https://github.com/rust-lang/rust/issues/15872#issuecomment-417953153), proposal (https://github.com/rust-lang/rust/issues/15872#issuecomment-412759783).
Tracking issue: https://github.com/rust-lang/rust/issues/15872
Usage examples (from libcore): https://github.com/rust-lang/rust/pull/54687
|
|
Enable one fully ignored test
|
|
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
|
|
|
|
It's already stable in 2018; this finishes the stabilization.
|
|
|
|
|
|
|
|
Add missing lifetime fragment specifier to error message.
A very minor issue, `lifetime` was missing from the error list.
I left `literal` in the list, even though it is unstable. It looks like it may stabilize soon anyways.
|
|
Issue: 54912
|
|
A very minor issue, `lifetime` was missing from the error list.
I left `literal` in the list, even though it is unstable. It looks like it may stabilize soon anyways.
|
|
Remove incorrect span for second label inner macro invocation
A fix for issue #54841
|
|
Improve error display for codeblocks in rustdoc
Part of #53919.
r? @QuietMisdreavus
|
|
r=nikomatsakis
Fix #54707 - parse_trait_item_ now handles interpolated blocks as function body decls
Fix #54707 - parse_trait_item_ now handles interpolated blocks as function body decls
Previously parsing trait items only handled opening brace token and semicolon, I added a branch to the match statement that will also handle interpolated blocks.
|
|
Given the following code, compile successfuly:
```
macro_rules! test {
(
fn fun() -> Option<Box<$t:ty>>;
) => {
fn fun(x: $t) -> Option<Box<$t>>
{ Some(Box::new(x)) }
}
}
test! {
fn fun() -> Option<Box<i32>>;
}
```
|
|
Fixes #47311.
r? @nrc
|
|
Fixes #47311.
r? @nrc
|
|
Fixes #47311.
r? @nrc
|
|
|
|
|
|
|
|
|
|
oli-obk:mögen_konstante_funktionen_doch_bitte_endlich_stabil_sein, r=Centril
Stabilize `min_const_fn`
tracking issue: #53555
r? @Centril
|
|
Issue: 54379
|
|
|
|
Does not implement the warning or a feature flag.
|
|
make `Parser::parse_foreign_item()` return a foreign item or error
Fixes `Parser::parse_foreign_item()` to follow the convention of `parse_trait_item()` and `parse_impl_item()` in that it *must* parse an item or return an error, and then the caller is responsible for detecting the closing delimiter.
This prevents it from looping endlessly on an unexpected token in `ext/expand.rs` where it was also leaking memory by continually pushing to `Parser::expected_tokens` via `Parser::check_keyword()`.
closes #54441
r? @petrochenkov
cc @dtolnay
|
|
add suggestion for inverted function parameters
Fixes #54065.
|
|
Fixes #54065.
|
|
resolve: Some refactorings in preparation for uniform paths 2.0
The main result is that in-scope resolution performed during macro expansion / import resolution is now consolidated in a single function (`fn early_resolve_ident_in_lexical_scope`), which can now be used for resolving first import segments as well when uniform paths are enabled.
r? @ghost
|
|
|
|
Merge `proc_macro_` expansion feature gates as `proc_macro_hygiene`
Merges `proc_macro_mod`, `proc_macro_expr`, `proc_macro_non_items`, and `proc_macro_gen` into a single feature: `proc_macro_hygiene`. These features are not all blocked on implementing macro hygiene *per se*, but rather on interactions with hygiene that have not been entirely resolved.
|
|
closes #54441
|
|
|
|
The restrictions were introduced in https://github.com/rust-lang/rust/pull/54277 and no longer necessary now because legacy plugins are now expanded in usual left-to-right order
|
|
abolish ICE when pretty-printing async block
@jnetterf reported an ICE when the unused-parentheses lint triggered around an async block (#54752). In order to compose an autofixable suggestion, the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead, to preserve the formatting of the original source?—but to answer that, you'd have to ask the author of 5c9f806d.)
But then the pretty-printer panics when trying to call `<pprust::State as PrintState>::end` when `State.boxes` is empty. Empirically, the problem would seem to be solved if we start some "boxes" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style`, exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty ("pretty") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks, right??
Of course, it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof, rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today, than with certainty in some indefinite hypothetical future? Maybe the effort is worth [a fifth of a shirt](https://hacktoberfest.digitalocean.com/stats/zackmdavis)??
Humbly resolves #54752.
r? @cramertj
|
|
|
