- 11 9月, 2018 3 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path. What is really necessary is its parent module, parent expansion and parent legacy scope. This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
-
由 bors 提交于
Feature gate non-builtin attributes in inner attribute position Closes item 3 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
-
- 10 9月, 2018 12 次提交
-
-
由 bors 提交于
rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate, on Rust 2018. This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests). Also, on top of #54005, this PR allows this as well: ```rust use crate_name; use crate_name::foo; ``` In that any ambiguity between an extern crate and an import *of that same crate* is ignored. r? @petrochenkov cc @aturon @Centril @joshtriplett
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 bors 提交于
#53359: putting multiple unresolved import on single line r? @estebank Here is WIP implementation of #53359 this PR have clubbed multiple unresolved imports into a single line. I think still two things need to improve like giving specific `label message` for each span of multi_span(how we can do this?) and second we are getting a warning while compiling, stating something like `E0432` have been passed before.
-
由 bors 提交于
if- and while-let-chains, take 2 - edition changes Part of #53668. r? @nikomatsakis
-
由 bors 提交于
resolve: Split macro prelude into built-in and user-defined parts This is a refactoring that will help to remove `unshadowable_attrs` when https://github.com/rust-lang/rust/pull/53410 lands. UPDATE: The second commit actually removes `unshadowable_attrs`.
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
resolve: Relax shadowing restrictions on macro-expanded macros Previously any macro-expanded macros weren't allowed to shadow macros from outer scopes. Now only "more macro-expanded" macros cannot shadow "less macro-expanded" macros. See comments to `fn may_appear_after` and added tests for more details and examples. The functional changes are a21f6f588fc28c97533130ae44a6957b579ab58c and 46dd365ce9ca0a6b8653849b80267763c542842a, other commits are refactorings.
-
由 bors 提交于
Stabilize edition 2018; also updates Clippy, RLS and Cargo Supersedes https://github.com/rust-lang/rust/pull/53999 , https://github.com/rust-lang/rust/pull/53935 Clippy build was failing there because crate_visibility_modifier feature was taken out of edition 2018 and clippy used it. The clippy update enables the corresponding feature explicitly. r? @Mark-Simulacrum
- 09 9月, 2018 13 次提交
-
-
由 bors 提交于
proc_macro::Group::span_open and span_close Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation: ```rust mod m { type T = } ``` ```console error: expected type, found `}` --> src/main.rs:3:1 | 3 | } | ^ ``` On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above. This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476. ```diff impl Group { fn span(&self) -> Span; + fn span_open(&self) -> Span; + fn span_close(&self) -> Span; } ``` Fixes #48187 r? @alexcrichton
-
https://github.com/rust-lang/rust/pull/53935/由 Eric Huss 提交于
(done by matthiaskrgr, but I authored ehuss)
-
由 bors 提交于
rustc_codegen_llvm: don't assume offsets are always aligned. Fixes #53728 by taking into account not just overall type alignment and the field's alignment when determining whether a field is aligned or not ("packed"), but also the field's offset within the type. Previously, rustc assumed that the offset was always at least as aligned as `min(struct.align, field.align)`. However, there's no real reason to have that assumption, and it obviously can't always be true after we implement `#[repr(align(N), pack(K))]`. There's also a case today where that assumption is not true, involving niche discriminants in enums: Suppose that we have the code in #53728: ```Rust #[repr(u16)] enum DeviceKind { Nil = 0, } #[repr(packed)] struct DeviceInfo { endianness: u8, device_kind: DeviceKind, } struct Wrapper { device_info: DeviceInfo, data: u32 } ``` Observe the layout of `Option<Wrapper>`. It has an alignment of 4 because of the `u32`. `device_info.device_kind` is a good niche field to use, which means the enum ends up with this layout: ``` size = 8 align = 4 fields = [ { offset=1, type=u16 } // discriminant, .<Some>.device_info.device_kind ] ``` And here we have an discriminant with alignment 2 (`u16`) but offset 1.
-
由 David Tolnay 提交于
-
由 bors 提交于
rustc_resolve: only prepend CrateRoot to a non-keyword segment. Fixes #53770 by treating `use` paths as absolute in a finer-grained manner, specifically: ```rust use {a, crate::b, self::c, super::d}; ``` Used to be interpreted as if it were (when `uniform_paths` is not enabled): ```rust use ::{a, crate::b, self::c, super::d}; ``` With this PR, the `CrateRoot` pseudo-keyword indicating an absolute path is only inserted when the first path segment is found (if it's not a keyword), i.e. the example behaves like: ```rust use {::a, crate::b, self::c, super::d}; ``` This should (finally) make `use {path};` fully equivalent to `use path;`. r? @petrochenkov cc @cramertj @joshtriplett @nikomatsakis
-
由 bors 提交于
Fix incorrect outer function type parameter message Fix #51303.
-
由 David Tolnay 提交于
-
由 bors 提交于
Improve messages for un-closed delimiter errors
-
由 Matthias Krüger 提交于
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
由 bors 提交于
Skip a shared borrow of a immutable local variables issue #53643 r? @nikomatsakis
-
由 bors 提交于
Optimize miri checking of integer array/slices This pull request implements the optimization described in #53845 (the `E-easy` part of that issue, not the refactoring). Instead of checking every element of an integral array, we can check the whole memory range at once. r? @RalfJung
-
- 08 9月, 2018 12 次提交
-
-
由 Pramod Bisht 提交于
Addressed estebank's comments for 53359
-
由 bors 提交于
#53576 Renaming TyAnon -> TyOpaque Fixes #53576
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #53315 (use `NonZeroU32` in `newtype_index!`macro, change syntax) - #53932 ([NLL] Remove base_place) - #53942 (Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.) - #53973 (Have rust-lldb look for the rust-enabled lldb) - #53981 (Implement initializer() for FileDesc) - #53987 (rustbuild: allow configuring llvm version suffix) - #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.) - #54007 (crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint) - #54040 (update books for next release) - #54050 (Update `petgraph` dependency to 0.4.13 to fix build with nightly)
-
由 Vadim Petrochenkov 提交于
Add labels to ambiguous resolution errors
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Whitelist `#[rustc_transparent_macro]` so it's not interpreted as a potential attribute macro
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
... for both legacy and modern macros. Fix previously introduced regressions, add tests.
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
This is a regression for legacy macros that will be fixed in the next commit
-