-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rollup of 7 pull requests #63028
Rollup of 7 pull requests #63028
Conversation
This commit adds a reproduction of the error reported in servo which demonstrates the current, incorrect behaviour. Co-authored-by: Rémy Rakić <[email protected]>
- Make sure we ban duplicate '..'. - Avoid ICEs on PatKind::Rest that doesn't generate HIR nodes.
- Make sure extra `x @ ..` do not cause ICEs.
The Dumper no longer has anything to do specifically with JSON, it merely represents processing into an `Analysis` output.
This commit implements a hacky fix for detecting when a span is pointing at a macro call site so that bare trait lints are not made incorrectly.
Define built-in macros through libcore This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`). All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler. The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope. As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change. Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`). Now when built-in macros have canonical definitions they can be imported or reexported without issues (rust-lang#61687). Other changes: - You can now define a derive macro with a name matching one of the built-in derives (rust-lang#52269). This was an artificial restriction that could be worked around with import renaming anyway. Known regressions: - Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type. Fixes rust-lang#61687 Fixes rust-lang#61804 r? @eddyb
Implement RFC 2707 + Parser recovery for range patterns Implement rust-lang/rfcs#2707. - Add a new basic syntactic pattern form `ast::PatKind::Rest` (parsed as `..` or `DOTDOT`) and simplify `ast::PatKind::{Slice, Tuple, TupleStruct}` as a result. - Lower `ast::PatKind::Rest` in combination with the aforementioned `PatKind` variants as well as `PatKind::Ident`. The HIR remains unchanged for now (may be advisable to make slight adjustments later). - Refactor `parser.rs` wrt. parsing sequences and lists of things in the process. - Add parser recovery for range patterns of form `X..`, `X..=`, `X...`, `..Y`, `..=Y`, and `...Y`. This should make it easy to actually support these patterns semantically later if we so desire. cc rust-lang#62254 r? @petrochenkov
Re-enable assertions in PPC dist builder Fixes rust-lang#36150 Log of successful build: https://dev.azure.com/mati865/6518b167-4cf6-4587-b3d1-8e137f2fb2e4/_apis/build/builds/23/logs/825
bump crossbeam-epoch dependency The new crossbeam-epoch release depends on a memoffset with a whole bunch of soundness holes fixed. The old memoffset is still indirectly depended on (at least) by rustc-rayon, though -- a crate that looks rather unmaintained (no change in more than a year).
… r=Xanewok Cleanup save-analysis JsonDumper
add `repr(transparent)` to `IoSliceMut` where missing tried using `IoSliceMut` in FFI, got `improper_ctypes` warning. according to the docs: `IoSliceMut` is "guaranteed to be ABI compatible with the `iovec` type" so it should be usable in FFI. `IoSlice` is also `repr(transparent)` for every platform where these types contain `iovec`-like types. vxworks also has `IoSliceMut` as transparent so its not even consistently one or the other. no comment about this next to the types or in the PR that introduced the types, so assuming this was just missed. r? @sfackler
…gestion, r=estebank Stop bare trait lint applying to macro call sites Fixes rust-lang#61963. Apologies for the delay with in fixing this. If anyone has a better idea how to detect this macro call site case, I'd be happy to fix this in a more robust, less hacky way. r? @estebank
@bors r+ p=7 rollup=never |
📌 Commit 17396c9 has been approved by |
⌛ Testing commit 17396c9 with merge 92414ad993ac7cdc3f3e59617886fa0e6876a14f... |
💔 Test failed - checks-azure |
Your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Successful merges:
repr(transparent)
toIoSliceMut
where missing #63013 (addrepr(transparent)
toIoSliceMut
where missing)Failed merges:
r? @ghost