- 02 7月, 2020 16 次提交
-
-
由 Manish Goregaokar 提交于
Clean up E0712 explanation r? @Dylan-DPC
-
由 Manish Goregaokar 提交于
Fix Zulip topic format Yet another instance of me making a mistake after copy-pasting :D r? @Dylan-DPC
-
由 Manish Goregaokar 提交于
Fix markdown rendering in librustc_lexer docs Use back-ticks instead of quotation marks in docs for the block comment variant of TokenKind. ## [Before](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/enum.TokenKind.html#variant.BlockComment) and after <img width="1103" alt="Screen Shot 2020-06-28 at 1 22 30 PM" src="https://user-images.githubusercontent.com/19642016/85957562-446a8380-b943-11ea-913a-442cf7744083.png"> <img width="1015" alt="Screen Shot 2020-06-28 at 1 28 29 PM" src="https://user-images.githubusercontent.com/19642016/85957566-4af8fb00-b943-11ea-8fef-a09c1d586772.png"> ## Question For visual consistency, should we use back-ticks throughout the docs for these enum variants?
-
由 Manish Goregaokar 提交于
Remove defunct `-Z print-region-graph`
-
由 Manish Goregaokar 提交于
Split and expand nonstandard-style lints unicode unit test. RFC 2457 requested that the `nonstandard_style` series of linted be adjusted to cover the non_ascii_identifier case. However when i read the code of those implementations, it seems they're already supporting non_ascii_identifiers. But the exact rules is a little different than what's proposed in RFC 2457. So I splitted and expanded the existing test case to try to exercise every branch in the code. I think it'll also be easier to examine the cases in these unit tests to see whether it's ok to just leave them as is, or some adjustments are needed. r? @Manishearth
-
由 Manish Goregaokar 提交于
Recover extra trailing angle brackets in struct definition This commit applies the existing 'extra angle bracket recovery' logic when parsing fields in struct definitions. This allows us to continue parsing the struct's fields, avoiding spurious 'missing field' errors in code that tries to use the struct.
-
由 Manish Goregaokar 提交于
Handle `macro_rules!` tokens consistently across crates When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition. This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case. To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from. This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group. See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
-
由 Manish Goregaokar 提交于
Provide more information on duplicate lang item error. This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing, and this might help in diagnosing what has happened. Here's an example when hitting a bug with Cargo's build-std: ``` error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`. | = note: the lang item is first defined in crate `core` (which `z10` depends on) = note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta = note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta ```
-
由 Manish Goregaokar 提交于
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791. Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as https://github.com/rust-lang/rust/pull/73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see https://github.com/rust-lang/rust/pull/62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
-
由 Manish Goregaokar 提交于
Don't implement Fn* traits for #[target_feature] functions Closes #72012.
-
由 Manish Goregaokar 提交于
Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very "legacy" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup, this closes #24397
-
由 bors 提交于
Test UI tests for pass=check I'm going to just compare the builder times since I wasn't able to get this working nicely locally (hit some obscure linker error). Fixes part of #69823
-
由 Vadim Petrochenkov 提交于
-
由 Aaron Hill 提交于
When a `macro_rules!` macro expands to another `macro_rules!` macro, we may see `None`-delimited groups in odd places when another crate deserializes the 'inner' macro. This commit 'unwraps' an outer `None`-delimited group to avoid breaking existing code. See https://github.com/rust-lang/rust/pull/73569#issuecomment-650860457 for more details. The proper fix is to handle `None`-delimited groups systematically throughout the parser, but that will require significant work. In the meantime, this hack lets us fix important hygiene bugs in macros
-
由 Aaron Hill 提交于
-
由 Aaron Hill 提交于
-
- 01 7月, 2020 24 次提交
-
-
由 bors 提交于
Rollup of 17 pull requests Successful merges: - #72071 (Added detailed error code explanation for issue E0687 in Rust compiler.) - #72369 (Bring net/parser.rs up to modern up to date with modern rust patterns) - #72445 (Stabilize `#[track_caller]`.) - #73466 (impl From<char> for String) - #73548 (remove rustdoc warnings) - #73649 (Fix sentence structure) - #73678 (Update Box::from_raw example to generalize better) - #73705 (stop taking references in Relate) - #73716 (Document the static keyword) - #73752 (Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other) - #73776 (Move terminator to new module) - #73778 (Make `likely` and `unlikely` const, gated by feature `const_unlikely`) - #73805 (Document the type keyword) - #73806 (Use an 'approximate' universal upper bound when reporting region errors) - #73828 (Fix wording for anonymous parameter name help) - #73846 (Fix comma in debug_assert! docs) - #73847 (Edit cursor.prev() method docs in lexer) Failed merges: r? @ghost
-
由 Manish Goregaokar 提交于
Edit cursor.prev() method docs in lexer Fix missing punctuation
-
由 Manish Goregaokar 提交于
Fix comma in debug_assert! docs
-
由 Manish Goregaokar 提交于
Fix wording for anonymous parameter name help ``` --> exercises/functions/functions2.rs:8:15 | 8 | fn call_me(num) { | ^ expected one of `:`, `@`, or `|` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) help: if this is a `self` type, give it a parameter name | 8 | fn call_me(self: num) { | ^^^^^^^^^ help: if this was a parameter name, give it a type | 8 | fn call_me(num: TypeName) { | ^^^^^^^^^^^^^ help: if this is a type, explicitly ignore the parameter name | 8 | fn call_me(_: num) { | ``` This commit changes "if this was a parameter name" to "if this is a parameter name" to match the wording of similar errors.
-
由 Manish Goregaokar 提交于
Use an 'approximate' universal upper bound when reporting region errors Fixes #67765 When reporting errors during MIR region inference, we sometimes use `universal_upper_bound` to obtain a named universal region that we can display to the user. However, this is not always possible - in a case like `fn foo<'a, 'b>() { .. }`, the only upper bound for a region containing `'a` and `'b` is `'static`. When displaying diagnostics, it's usually better to display *some* named region (even if there are multiple involved) rather than fall back to a generic error involving `'static`. This commit adds a new `approx_universal_upper_bound` method, which uses the lowest-numbered universal region if the only alternative is to return `'static`.
-
由 Manish Goregaokar 提交于
Document the type keyword Partial fix of #34601. Two small examples, one clarifying that `type` only defines an alias, not a completely new type, the other explaining the use in traits. @rustbot modify labels: T-doc,C-enhancement
-
由 Manish Goregaokar 提交于
Make `likely` and `unlikely` const, gated by feature `const_unlikely` This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`. cc @RalfJung @nagisa r? @oli-obk
-
由 Manish Goregaokar 提交于
Move terminator to new module Moves terminator types from `librustc_middle/mir/mod.rs` into submodule Fixes #73723
-
由 Manish Goregaokar 提交于
Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other I don't know if this is acceptable or how likely it is to break existing code, but it seem to me ERROR_INVALID_PARAMETER "The parameter is incorrect" should map to ErrorKind::InvalidInput "A parameter was incorrect". Previously this value fell through to ErrorKind::Other. I can't speak for anyone but myself, but I instinctively thought it would be InvalidInput.
-
由 Manish Goregaokar 提交于
Document the static keyword Partial fix of #34601. This documents the `static` keyword. It's basically a simplified version of the reference with more examples. @rustbot modify labels: T-doc,C-enhancement
-
由 Manish Goregaokar 提交于
stop taking references in Relate Adds a `Copy` bound to `Relate` and changes the type signatures to `T` from `&T`. While the `Copy` bound is not strictly necessary (i.e. the `Clone` bound of `TypeRelation` would be good enough), we don't need non `Copy` types and it simplifies the implementation. Removes the afaict unused impls for `Vec<ty::PolyExistentialProjection<'tcx>>`, `Rc<T>` and `Box<T>`. If they end up being relevant again the bound of `Relate` can be reduced to `T: Clone`. This also changes signature of `Binder::skip_binder` to `fn skip_binder(self) -> T`. `TypeError::ProjectionBoundsLength` was never used and is also removed in this PR. r? @nikomatsakis maybe
🤔 feel free to reassign -
由 Manish Goregaokar 提交于
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
-
由 Manish Goregaokar 提交于
Fix sentence structure Fixed grammar and sentence structure on appropriate instances.
-
由 Manish Goregaokar 提交于
remove rustdoc warnings
-
由 Manish Goregaokar 提交于
impl From<char> for String This allows us to write ````rust fn char_to_string() -> String { 'a'.into() } ```` which was not possible before.
-
由 Manish Goregaokar 提交于
Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42, we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo, ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
-
由 Manish Goregaokar 提交于
Bring net/parser.rs up to modern up to date with modern rust patterns The current implementation of IP address parsing is very unidiomatic; it's full of `if` / `return` / `is_some` / `is_none` instead of `?`, `loop` with manual index tracking; etc. Went through and did and cleanup to try to bring it in line with modern sensibilities. The obvious concern with making changes like this is "make sure you understand why it's written that way before changing it". Looking through the commit history for this file, there are several much smaller commits that make similar changes (For instance, https://github.com/rust-lang/rust/commit/3024c1434a667425d30e4b0785857381323712aa, https://github.com/rust-lang/rust/commit/4f3ab4986ec96d9c93f34dc53d0a4a1279288451, https://github.com/rust-lang/rust/commit/79f876495b2853d1b78ba953ceb3114b8019100f), and there don't seem to be any commits in the history that indicate that this lack of idiomaticity is related to specific performance needs (ie, there aren't any commits that replace a `for` loop with a `loop` and a manual index count). In fact, the basic shape of the file is essentially unchanged from its initial commit back in 2015. Made the following changes throughout the IP address parser: - Replaced all uses of `is_some()` / `is_none()` with `?`. - "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc. - Removed all cases of manual index tracking / incrementing. - Renamed several single-character variables with more expressive names. - Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`). - Removed `read_seq_3`; replaced with simple sequences of `?`. - Parser now reslices its state when consuming, rather than carrying a separate state and index variable. - `read_digit` now uses `char::to_digit`. - Added comments throughout, especially in the complex IPv6 parsing logic. - Added comprehensive local unit tests for the parser to validate these changes.
-
由 Manish Goregaokar 提交于
Added detailed error code explanation for issue E0687 in Rust compiler. Added proper error explanation for issue E0687 in the Rust compiler. Error Code E0687 Sub Part of Issue #61137 r? @GuillaumeGomez
-
由 Mark Rousskov 提交于
We do not test cross-compilation here as the PR builder lacks a sufficiently recent LLVM to cross-compile to 32-bit linux. Once we bump the minimum LLVM version to LLVM 9, this can use normal 32-bit linux.
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
Revert "ci: allow gating gha on everything but macOS" The macOS issue on GHA's side seems to be fixed, so this is not needed anymore. r? @Mark-Simulacrum
-
由 Vadim Petrochenkov 提交于
-
由 Adam Perry 提交于
Does not yet make its constness stable, though. Use of `Location::caller` in const contexts is still gated by `#![feature(const_caller_location)]`.
-
由 bors 提交于
Serialize all foreign `SourceFile`s into proc-macro crate metadata Normally, we encode a `Span` that references a foreign `SourceFile` by encoding information about the foreign crate. When we decode this `Span`, we lookup the foreign crate in order to decode the `SourceFile`. However, this approach does not work for proc-macro crates. When we load a proc-macro crate, we do not deserialzie any of its dependencies (since a proc-macro crate can only export proc-macros). This means that we cannot serialize a reference to an upstream crate, since the associated metadata will not be available when we try to deserialize it. This commit modifies foreign span handling so that we treat all foreign `SourceFile`s as local `SourceFile`s when serializing a proc-macro. All `SourceFile`s will be stored into the metadata of a proc-macro crate, allowing us to cotinue to deserialize a proc-macro crate without needing to load any of its dependencies. Since the number of foreign `SourceFile`s that we load during a compilation session may be very large, we only serialize a `SourceFile` if we have also serialized a `Span` which requires it.
-