| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This introduces the new type -- Semantics.
Semantics maps SyntaxNodes to various semantic info, such as type,
name resolution or macro expansions.
To do so, Semantics maintains a HashMap which maps every node it saw
to the file from which the node originated. This is enough to get all
the necessary hir bits just from syntax.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3026: ra_syntax: reshape SyntaxError for the sake of removing redundancy r=matklad a=Veetaha
Followup of #2911, also puts some crosses to the todo list of #223.
**AHTUNG!** A big part of the diff of this PR are test data files changes.
Simplified `SyntaxError` that was `SyntaxError { kind: { /* big enum */ }, location: Location }` to `SyntaxError(String, TextRange)`. I am not sure whether the tuple struct here is best fit, I am inclined to add names to the fields, because I already provide getters `SyntaxError::message()`, `SyntaxError::range()`.
I also removed `Location` altogether ...
This is currently WIP, because the following is not done:
- [ ] ~~Add tests to `test_data` dir for unescape errors *// I don't know where to put these errors in particular, because they are out of the scope of the lexer and parser. However, I have an idea in mind that we move all validators we have right now to parsing stage, but this is up to discussion...*~~ **[UPD]** I came to a conclusion that tree validation logic, which unescape errors are a part of, should be rethought of, we currently have no tests and no place to put tests for tree validations. So I'd like to extract potential redesign (maybe move of tree validation to ra_parser) and adding tests for this into a separate task.
Co-authored-by: Veetaha <[email protected]>
Co-authored-by: Veetaha <[email protected]>
|
| | |
|
| |
| |
| |
| | |
constructed from TextUnit
|
| |
| |
| |
| | |
as per matklad
|
| |
| |
| |
| | |
per matklad
|
| | |
|
| | |
|
| | |
|
| |
| |
| | |
Co-Authored-By: Aleksey Kladov <[email protected]>
|
| |
| |
| | |
Co-Authored-By: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3062: Implement slice pattern AST > HIR lowering r=jplatte a=jplatte
WIP. The necessary changes for parsing are implemented, but actual inference is not yet. Just wanted to upload what I've got so far so it doesn't get duplicated :)
Will fix #3043
Co-authored-by: Jonas Platte <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Make capitalization more consistent and fix some typos.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3047: Update async unsafe fn ordering in parser r=matklad a=kiljacken
As of rust-lang/rust#61319 the correct order for functions that are both unsafe and async is: `async unsafe fn` and not `unsafe async fn`.
This commit updates the parser tests to reflect this, and corrects parsing behavior to accept the correct ordering.
Fixes #3025
Co-authored-by: Emil Lauridsen <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As of rust-lang/rust#61319 the correct order for functions that are both
unsafe and async is: `async unsafe fn` and not `unsafe async fn`.
This commit updates the parser tests to reflect this, and corrects
parsing behavior to accept the correct ordering.
Fixes #3025
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
3040: Rework value parameter parsing r=matklad a=tobz1000
Fixes #2847.
- `Fn__(...)` parameters with idents/patterns no longer parse
- Trait function parameters with arbitrary patterns parse
- Trait function parameters without idents/patterns no longer parse
- `fn(...)` parameters no longer parse with patterns other than a single ident
__Question__: The pre-existing test `param_list_opt_patterns` has been kept as-is, although the name no longer makes sense (it's testing `Fn__(...)` params, which aren't allowed patterns any more). What would be best to do about this?
Co-authored-by: Toby Dimmick <[email protected]>
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- `Fn__(...)` parameters with idents/patterns no longer parse
- Trait function parameters with arbitrary patterns parse
- Trait function parameters without idents/patterns no longer parse
- `fn(...)` parameters no longer parse with patterns other than a single ident
|
| | | |
|
| |/
|/| |
|
|/ |
|