about summary refs log tree commit diff
path: root/src/libcore/macros.rs
AgeCommit message (Collapse)AuthorLines
2019-11-14Centralize panic macro documentationChris Gregory-1328/+0
2019-11-12Snap cfgsMark Rousskov-24/+0
2019-11-08add link to unstable book for asm! macroLzu Tao-0/+4
2019-10-30caller_location: use in core::panic!.Eduard-Mihai Burtescu-17/+15
2019-10-27Panicking infra uses &core::panic::Location.Adam Perry-1/+34
This allows us to remove `static_panic_msg` from the SSA<->LLVM boundary, along with its fat pointer representation for &str. Also changes the signature of PanicInfo::internal_contructor to avoid copying. Closes #65856.
2019-10-23Document guard expressions in `matches!`Simon Sapin-1/+4
2019-10-23Add tracking issue for the `matches!` macroSimon Sapin-1/+1
https://github.com/rust-lang/rust/issues/65721
2019-10-23Move the `matches!` macro to the preludeSimon Sapin-0/+24
2019-10-08Rollup merge of #64726 - andrewbanchich:unimplemented, r=rkruppeMazdak Farrokhzad-15/+32
rewrite documentation for unimplemented! to clarify use The current docs for `unimplemented!` seem to miss the point of this macro. > This can be useful if you are prototyping and are just looking to have your code type-check, or if you're implementing a trait that requires multiple methods, and you're only planning on using one of them. You could also return a `()` if you just want your code to type-check. I think `unimplemented!` is useful for when you want your program to exit when it reaches an unimplemented area. I rewrote the explanation and gave examples of both forms of this macro that I think clarify its use a little better.
2019-10-06rewrite documentation for unimplemented!Andrew Banchich-15/+32
2019-10-03Rollup merge of #61879 - stjepang:stabilize-todo, r=withoutboatsTyler Mandry-6/+10
Stabilize todo macro The `todo!` macro is just another name for `unimplemented!`. Tracking issue: https://github.com/rust-lang/rust/issues/59277 This PR needs a FCP to merge. r? @withoutboats
2019-09-25Snap cfgs to new betaMark Rousskov-4/+2
2019-09-23Move `--cfg bootstrap` out of `rustc.rs`Alex Crichton-2/+2
Instead let's do this via `RUSTFLAGS` in `builder.rs`. Currently requires a submodule update of `stdarch` to fix a problem with previous compilers.
2019-09-07Support "soft" feature-gating using a lintVadim Petrochenkov-2/+4
Use it for feature-gating `#[bench]`
2019-09-04Update macros.rsStjepan Glavina-1/+1
2019-09-04Update src/libcore/macros.rsStjepan Glavina-1/+1
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-08-23Remove default macro transparenciesVadim Petrochenkov-8/+0
All transparancies are passed explicitly now. Also remove `#[rustc_macro_transparency]` annotations from built-in macros, they are no longer used. `#[rustc_macro_transparency]` only makes sense for declarative macros now.
2019-08-17Make built-in derives opaque macrosMatthew Jasper-2/+2
2019-08-15Remove `__rust_unstable_column`Vadim Petrochenkov-8/+1
2019-08-15Hygienize use of built-in macros in the standard libraryVadim Petrochenkov-13/+13
2019-08-14Handle cfg(bootstrap) throughoutMark Rousskov-35/+0
2019-08-10Give built-in macros stable addresses in the standard libraryVadim Petrochenkov-122/+63
2019-08-09Rollup merge of #63114 - matthewjasper:hygienic-format-args, r=petrochenkovMazdak Farrokhzad-2/+0
Remove gensym in format_args This also fixes some things to allow us to export opaque macros from libcore: * Don't consider items that are only reachable through opaque macros as public/exported (so they aren't linted as needing docs) * Mark private items reachable from the root of libcore as unstable - they are now reachable (in principle) in other crates via macros in libcore r? @petrochenkov
2019-08-09Postpone deprecating try! until 1.39.0Lzu Tao-1/+1
2019-08-09Deprecate `try!` macroBO41-0/+1
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Co-Authored-By: Oliver Middleton <olliemail27@gmail.com>
2019-08-08Improved documentation for compile_error!()SOFe-1/+1
Fixes #63375
2019-08-05Remove gensym from format_argsMatthew Jasper-2/+0
2019-08-02Rollup merge of #62663 - llogiq:more-questionmark-docs, r=GuillaumeGomezMazdak Farrokhzad-16/+27
More questionmarks in doctests This removes the other `unwrap`s in the macro doctests, replacing them with `?`. For now, we need to specify the main function including the return type, we can get rid of that once the return type suggestion for `fn main() { .. }` works correctly. r? @QuietMisdreavus
2019-08-01More questionmarks in doctestsAndre Bogus-16/+27
2019-07-31Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`Vadim Petrochenkov-25/+2
2019-07-26Introduce built-in macros through libcoreVadim Petrochenkov-7/+7
2019-07-24syntax_ext: Turn `#[global_allocator]` into a regular attribute macroVadim Petrochenkov-0/+7
2019-07-21use a const to hack around promotion limitationsRalf Jung-1/+1
2019-07-19use const array repeat expressions for uninit_arrayRalf Jung-3/+20
2019-07-11Remove unnecessary expansions created by `#[test_case/test/bench]`Vadim Petrochenkov-0/+3
The expansions were created to allow unstable things inside `#[test_case/test/bench]`, but that's not a proper way to do that. Put the required `allow_internal_unstable`s into the macros' properties instead.
2019-07-09Apply suggestions from code reviewAleksey Kladov-3/+3
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-07-09clarify that debug_assert does not completely omits the codeAleksey Kladov-6/+6
TIL that debug_assert is implemented using `if cfg!(debug_assertions)` rather than `#[cfg(debug_assertions)]`. This means one can not use API gated with `#[cfg(debug_assertions)]` in `debug_assert` family of macros.
2019-07-07Rollup merge of #61990 - llogiq:questionmark-test, r=QuietMisdreavusMazdak Farrokhzad-4/+7
First question mark in doctest We have had `?` for `Result`s in doctests for some time, but so far haven't used them in doctests. With this PR, I want to start the de-`unwrap`ping of doctests – and the discussion on where to do so. There is one downside, which is that the code can no longer be copied into a plain `main()` method, on the other hand, there should be a workable error if one does this.
2019-07-06Improve documentation for built-in macrosVadim Petrochenkov-76/+613
2019-07-06`#[rustc_doc_only_macro]` -> `#[rustc_builtin_macro]`Vadim Petrochenkov-16/+16
2019-07-03First question mark in doctestAndre Bogus-4/+7
2019-06-23Fix meta-variable binding errors in macrosJulien Cretin-3/+3
The errors are either: - The meta-variable used in the right-hand side is not bound (or defined) in the left-hand side. - The meta-variable used in the right-hand side does not repeat with the same kleene operator as its binder in the left-hand side. Either it does not repeat enough, or it uses a different operator somewhere. This change should have no semantic impact.
2019-06-16Stabilize todo macroStjepan Glavina-6/+10
2019-06-12Hygienize macros in the standard libraryVadim Petrochenkov-11/+11
2019-05-23Remove phrase "instead of a panic!"Brent Kerby-1/+1
2019-05-23Clarify docs for unreachable! macroBrent Kerby-3/+4
2019-03-28Rollup merge of #59448 - benesch:macro-doc, r=CentrilMazdak Farrokhzad-22/+23
Use consistent phrasing for all macro summaries None
2019-03-26Use consistent phrasing for all macro summariesNikhil Benesch-22/+23
2019-03-26adjust MaybeUninit API to discussionsRalf Jung-2/+2
uninitialized -> uninit into_initialized -> assume_init read_initialized -> read set -> write
2019-03-18Add todo!() macroAleksey Kladov-0/+59
The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 10:54:18 +0000