- 18 1月, 2014 3 次提交
-
-
由 Jack Moffitt 提交于
-
由 Jack Moffitt 提交于
-
由 Jack Moffitt 提交于
This fixes a bug where new syntax crate IDs would cause rustpkg to fail to build crates.
-
- 17 1月, 2014 26 次提交
-
-
由 bors 提交于
Major changes: - Define temporary scopes in a syntax-based way that basically defaults to the innermost statement or conditional block, except for in a `let` initializer, where we default to the innermost block. Rules are documented in the code, but not in the manual (yet). See new test run-pass/cleanup-value-scopes.rs for examples. - Refactors Datum to better define cleanup roles. - Refactor cleanup scopes to not be tied to basic blocks, permitting us to have a very large number of scopes (one per AST node). - Introduce nascent documentation in trans/doc.rs covering datums and cleanup in a more comprehensive way. r? @pcwalton
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 bors 提交于
to fix https://github.com/mozilla/rust/issues/11218
-
由 Niko Matsakis 提交于
so that the "innermost enclosing statement" used for rvalue temporaries matches up with user expectations
-
由 Niko Matsakis 提交于
too. Previously I had omitted this case since function calls don't get the same treatment on the RHS, but it's different on the pattern and is more consistent -- the goal is to identify `let` statements where `ref` bindings create interior pointers.
-
由 Niko Matsakis 提交于
-
由 bors 提交于
The test run summary currently prints the wrong number of tests run. This PR fixes it by adding a newline to the log output, and also adds support for counting bench runs. Closes #11381
-
由 bors 提交于
Use a lookup table, SHIFT_MASK_TABLE, that for every possible four bit prefix holds the number of times the value should be right shifted and what the right shifted value should be masked with. This way we can get rid of the branches which in my testing gives approximately a 2x speedup. Timings on Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz -- Before -- running 5 tests test ebml::tests::test_vuint_at ... ok test ebml::bench::vuint_at_A_aligned ... bench: 494 ns/iter (+/- 3) test ebml::bench::vuint_at_A_unaligned ... bench: 494 ns/iter (+/- 4) test ebml::bench::vuint_at_D_aligned ... bench: 467 ns/iter (+/- 5) test ebml::bench::vuint_at_D_unaligned ... bench: 467 ns/iter (+/- 5) -- After -- running 5 tests test ebml::tests::test_vuint_at ... ok test ebml::bench::vuint_at_A_aligned ... bench: 181 ns/iter (+/- 2) test ebml::bench::vuint_at_A_unaligned ... bench: 192 ns/iter (+/- 1) test ebml::bench::vuint_at_D_aligned ... bench: 181 ns/iter (+/- 3) test ebml::bench::vuint_at_D_unaligned ... bench: 197 ns/iter (+/- 6)
-
由 Niko Matsakis 提交于
-
由 bors 提交于
-
由 klutzy 提交于
`xorpush_test` and `test_marksof` are at `syntax::ast_util`. Fixes #7952
-
由 klutzy 提交于
-
由 klutzy 提交于
driver::session::crate_metadata is unused; removed.
-
由 bors 提交于
Turns out there is no documentation of a block expression in the rust manual currently! I deleted the "record expressions" section to make room for a "block expressions" section. Closes #3862
-
由 bors 提交于
This is a first pass on support for procedural macros that aren't hardcoded into libsyntax. It is **not yet ready to merge** but I've opened a PR to have a chance to discuss some open questions and implementation issues. Example ======= Here's a silly example showing off the basics: my_synext.rs ```rust #[feature(managed_boxes, globs, macro_registrar, macro_rules)]; extern mod syntax; use syntax::ast::{Name, token_tree}; use syntax::codemap::Span; use syntax::ext::base::*; use syntax::parse::token; #[macro_export] macro_rules! exported_macro (() => (2)) #[macro_registrar] pub fn macro_registrar(register: |Name, SyntaxExtension|) { register(token::intern(&"make_a_1"), NormalTT(@SyntaxExpanderTT { expander: SyntaxExpanderTTExpanderWithoutContext(expand_make_a_1), span: None, } as @SyntaxExpanderTTTrait, None)); } pub fn expand_make_a_1(cx: &mut ExtCtxt, sp: Span, tts: &[token_tree]) -> MacResult { if !tts.is_empty() { cx.span_fatal(sp, "make_a_1 takes no arguments"); } MRExpr(quote_expr!(cx, 1i)) } ``` main.rs: ```rust #[feature(phase)]; #[phase(syntax)] extern mod my_synext; fn main() { assert_eq!(1, make_a_1!()); assert_eq!(2, exported_macro!()); } ``` Overview ======= Crates that contain syntax extensions need to define a function with the following signature and annotation: ```rust #[macro_registrar] pub fn registrar(register: |ast::Name, ext::base::SyntaxExtension|) { ... } ``` that should call the `register` closure with each extension it defines. `macro_rules!` style macros can be tagged with `#[macro_export]` to be exported from the crate as well. Crates that wish to use externally loadable syntax extensions load them by adding the `#[phase(syntax)]` attribute to an `extern mod`. All extensions registered by the specified crate are loaded with the same scoping rules as `macro_rules!` macros. If you want to use a crate both for syntax extensions and normal linkage, you can use `#[phase(syntax, link)]`. Open questions =========== * ~~Does the `macro_crate` syntax make sense? It wraps an entire `extern mod` declaration which looks a bit weird but is nice in the sense that the crate lookup logic can be identical between normal external crates and external macro crates. If the `extern mod` syntax, changes, this will get it for free, etc.~~ Changed to a `phase` attribute. * ~~Is the magic name `macro_crate_registration` the right way to handle extension registration? It could alternatively be handled by a function annotated with `#[macro_registration]` I guess.~~ Switched to an attribute. * The crate loading logic lives inside of librustc, which means that the syntax extension infrastructure can't directly access it. I've worked around this by passing a `CrateLoader` trait object from the driver to libsyntax that can call back into the crate loading logic. It should be possible to pull things apart enough that this isn't necessary anymore, but it will be an enormous refactoring project. I think we'll need to create a couple of new libraries: libsynext libmetadata/ty and libmiddle. * Item decorator extensions can be loaded but the `deriving` decorator itself can't be extended so you'd need to do e.g. `#[deriving_MyTrait] #[deriving(Clone)]` instead of `#[deriving(MyTrait, Clone)]`. Is this something worth bothering with for now? Remaining work =========== - [x] ~~There is not yet support for rustdoc downloading and compiling referenced macro crates as it does for other referenced crates. This shouldn't be too hard I think.~~ - [x] ~~This is not testable at stage1 and sketchily testable at stages above that. The stage *n* rustc links against the stage *n-1* libsyntax and librustc. Unfortunately, crates in the test/auxiliary directory link against the stage *n* libstd, libextra, libsyntax, etc. This causes macro crates to fail to properly dynamically link into rustc since names end up being mangled slightly differently. In addition, when rustc is actually installed onto a system, there are actually do copies of libsyntax, libstd, etc: the ones that user code links against and a separate set from the previous stage that rustc itself uses. By this point in the bootstrap process, the two library versions *should probably* be binary compatible, but it doesn't seem like a sure thing. Fixing this is apparently hard, but necessary to properly cross compile as well and is being tracked in #11145.~~ The offending tests are ignored during `check-stage1-rpass` and `check-stage1-cfail`. When we get a snapshot that has this commit, I'll look into how feasible it'll be to get them working on stage1. - [x] ~~`macro_rules!` style macros aren't being exported. Now that the crate loading infrastructure is there, this should just require serializing the AST of the macros into the crate metadata and yanking them out again, but I'm not very familiar with that part of the compiler.~~ - [x] ~~The `macro_crate_registration` function isn't type-checked when it's loaded. I poked around in the `csearch` infrastructure a bit but didn't find any super obvious ways of checking the type of an item with a certain name. Fixing this may also eliminate the need to `#[no_mangle]` the registration function.~~ Now that the registration function is identified by an attribute, typechecking this will be like typechecking other annotated functions. - [x] ~~The dynamic libraries that are loaded are never unloaded. It shouldn't require too much work to tie the lifetime of the `DynamicLibrary` object to the `MapChain` that its extensions are loaded into.~~ - [x] ~~The compiler segfaults sometimes when loading external crates. The `DynamicLibrary` reference and code objects from that library are both put into the same hash table. When the table drops, due to the random ordering the library sometimes drops before the objects do. Once #11228 lands it'll be easy to fix this.~~
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Fix test to account for new temporary lifetime rules, which cause the channel to be dropped prematurely.
-
由 Steven Fackler 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Consider all zero-sized data structures to be voidish, bypassing some "quirky" parts of LLVM (see e.g. LLVM bug 9900) but also generating better code
-
由 bors 提交于
There might be a reason, but I failed to see why these comments couldn't be proper rust docs.
-
由 Alex Crichton 提交于
Closes #3862
-
由 bors 提交于
-
- 16 1月, 2014 11 次提交
-
-
由 Derek Guenther 提交于
-
由 bors 提交于
An enum allows callers to deal with errors in a more reasonable way.
-
由 bors 提交于
-
由 Seo Sanghyeon 提交于
-
由 bors 提交于
Closes #10893 - because we'll no longer build llvm-c-test
-
由 bors 提交于
This is a bit cleaner and means we don't need whitespace at the end of each line to force line breaks.
-
由 Niko Matsakis 提交于
-
由 bors 提交于
WindowsPath::new("C:").join("a") produces r"C:". This is incorrect. It should produce "C:a".
-
由 Steven Fackler 提交于
An enum allows callers to deal with errors in a more reasonable way.
-
由 Derek Chiang 提交于
-
由 Derek Chiang 提交于
-