This commit fed5a41fb1 introduced the concat
builtin macro but the error handling here is producing an infinite loop
which was not caught during code-review. This patch disables the offending
error cases so that it does not impact further development.
Addresses #1102
1090: macros: add concat! macro r=philberty a=liushuyu
- extracts parenthesis-matching logic into a function
- adds `concat!` macro
1097: Support mangling *const ptr and slices like *const [T] r=philberty a=philberty
The legacy mangling scheme needs to convert the canonical path containing
* for pointers and the [] brackets representing slices into:
* = $BP$
[ = $u5b$
] = $u5d$
These symbols are not allowed in asm symbols.
Addresses #849
1098: Ensure unsize method resolutions actually unsize r=philberty a=philberty
This was a typo when unsized method resolution was added, where the
adjustment was wrongly marked as an indirection. The enum is required so
that the code generation adjustment takes place.
Addresses #849
1099: Fix bad inherent overlap error r=philberty a=philberty
When we examine HIR::ImplBlock's we determine if an impl might overlap
another impl based on the Self type. So for example you might have a
generic structure Foo<T>(T), and an associated impl block for Foo<i32>, but
then go on to define an associated impl of Foo<T> the generic one will
overlap any associated impl hiding the generic implementation.
In this case we have two generic impl blocks
*const [T]
*const T
This means the *const T might overlap with the slice one since it is
generic. As bjorn3 pointed out in #1075 , the correct implementation is to
observe that [T] is constrained by size but untill we have the auto trait
of Sized we must example the two generic impls and just determine that
they are not-equal so for now this is the best implementation we can do.
Fixes#1075
1101: Add helper as_string for DefIds r=philberty a=philberty
This just adds a useful helper to as_string DefId's directly
Co-authored-by: liushuyu <liushuyu011@gmail.com>
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
When we examine HIR::ImplBlock's we determine if an impl might overlap
another impl based on the Self type. So for example you might have a
generic structure Foo<T>(T), and an associated impl block for Foo<i32>, but
then go on to define an associated impl of Foo<T> the generic one will
overlap any associated impl hiding the generic implementation.
In this case we have two generic impl blocks
*const [T]
*const T
This means the *const T might overlap with the slice one since it is
generic. As bjorn3 pointed out in #1075, the correct implementation is to
observe that [T] is constrained by size but untill we have the auto trait
of Sized we must example the two generic impls and just determine that
they are not-equal so for now this is the best implementation we can do.
Fixes#1075
1100: Add known lang item const_slice_ptr mappings r=philberty a=philberty
This will allow us to define the const_slice_ptr lang item attribute
without erroring out as an unknown lang item.
Addresses #849
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
This was a typo when unsized method resolution was added, where the
adjustment was wrongly marked as an indirection. The enum is required so
that the code generation adjustment takes place.
Addresses #849
The legacy mangling scheme needs to convert the canonical path containing
* for pointers and the [] brackets representing slices into:
* = $BP$
[ = $u5b$
] = $u5d$
These symbols are not allowed in asm symbols.
Addresses #849
1092: gcc/rust/Make-lang.in: add missing rust compiler driver r=philberty a=RomainNaour
When building gccrs with Buildroot toolchain infrastructure, the gccrs
compiler driver is missing when intalling gcc.
This is due to missing depedency on gccrs$(exeext) in rust.all.cross
target.
With that fixed, the gcc toolchain with Rust support is correctly installed into Buildroot:
$ ./test/gccrs/host/bin/aarch64-linux-gccrs --version
aarch64-linux-gccrs (Buildroot 2022.02-442-g54d638fbd1-dirty) 12.0.1 20220118 (experimental)
Note: We probably needs gccrs-cross target like other supported languages.
Copyright assignment signed between Smile and the FSF to contribute to GNU tools.
Co-authored-by: Romain Naour <romain.naour@smile.fr>
1087: Use loop to initialize repeat arrays r=philberty a=dafaust
This PR changes how we compile initializers for arrays of repeating elements. I use the same approach outlined in the comments of the linked issue, with some tweaks. It is very similar to how the D language front-end compiles, the new function `Gcc_backend::array_initializer` is heavily inspired by the D front-end's `build_array_set`
This fixes the issue where the compiler tries to allocate a vec containing all elements of the array to be constructed, and therefore explodes on huge constructions (e.g. `let x = [0u8; 4 * 1024 * 1024 * 1024 * 1024]`)
However, we can only initialize non-const arrays in this way. For arrays in const contexts we must initialize them at compile time, and therefore continue using the old method.
Fixes: #1068
Co-authored-by: David Faust <david.faust@oracle.com>
When building gccrs with Buildroot toolchain infrastructure, the gccrs
compiler driver is missing when intalling gcc.
This is due to missing depedency on gccrs$(exeext) in rust.all.cross
target.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
---
We probably needs gccrs-cross target like other supported languages.
This commit changes how arrays of repeating elements, e.g. [5; 12] are
compiled. Rather than create a constructor which explicitly initializes
each element to the given value (which causes compiler OOM for large
arrays), we emit instructions to allocate the array then initialize the
elements in a loop.
However, we can only take this approach outside of const contexts -
const arrays must still use the old approach.
1083: bugfix: fix several minor issues r=CohenArthur a=liushuyu
- Fixed `-frust-crate= option` got incorrectly overridden by a default value (`example`)
- Fix a minor typo in `gcc/rust/ast/rust-ast-full-test.cc`
Co-authored-by: liushuyu <liushuyu011@gmail.com>
1071: Allow transcribing of zero nodes in certain cases r=CohenArthur a=CohenArthur
When expanding AST fragments containing multiple nodes, we must be aware
that some cases allow expanding zero or more nodes. Any macro
transcription that gets parsed as many nodes (ie any transcriber function that calls `parse_many`) needs to be able to parse zero of those nodes and still get expanded properly (basically, removed).
Previously, this would cause a failure to lower the macro invocation which would remain as a child instead of getting stripped/erased.
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
When expanding AST fragments containing multiple nodes, we must be aware
that some cases allow expanding zero or more nodes. Any macro
transcription that gets parsed as many nodes (ie any transcriber function that calls `parse_many`) needs to be able to parse zero of those nodes and still get expanded properly (basically, removed).
Previously, this would cause a failure to lower the macro invocation which would remain as a child instead of getting stripped/erased.
Co-authored-by: philberty <philip.herron@embecosm.com>
1069: Handle macro invocations in type contexts r=CohenArthur a=CohenArthur
Closes#1067
This highlighted two issues where parsing types is not entirely correct, which I'll raise. The code necessary to handle macro invocations in these two places should already be implemented.
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
Macro invocations can be present where the language expects types. Thus,
we need to add a new type of parsing context, a new transcriber, as well
as a new way to extract types from the AST Fragments. This adds a lot of
"expansion places" in the attribute visitor, as types can be present in
a wide variety of constructs
1045: Add initial support for unsized method resolution r=philberty a=philberty
In order to support slices, we end up with an operator overload call of:
```
impl<T, I> Index<I> for [T]
where
I: SliceIndex<[T]>,
{
type Output = I::Output;
fn index(&self, index: I) -> &I::Output {
index.index(self)
}
}
```
So this means the self, in this case, is an array[T,capacity] and the index parameter is of type Range<usize>. In order to actually call this method
which has a self parameter of [T] we need to be able to 'unsize' the array
into a slice.
Addresses #849
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
Since all cases in the switch were handled, this was not really a
problem. Still, we should avoid those in case we need to add
delimiters at some point
Co-authored-by: Thomas Schwinge <thomas@schwinge.name>
1063: Handle :meta fragments properly r=CohenArthur a=CohenArthur
This expands :meta fragments properly and allows us to strip assignment expressions
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
1055: Allow keeping list of last matches to check against r=CohenArthur a=CohenArthur
When trying to figure out if a match can follow another, we must figure
out whether or not that match is in the follow-set of the other. If that
match is zeroable (i.e a repetition using the * or ? kleene operators),
then we must be able to check the match after them: should our current
match not be present, the match after must be part of the follow-set.
This commits allows us to performs such checks properly and to "look
past" zeroable matches. This is not done with any lookahead, simply by
keeping a list of pointers to possible previous matches and checking all
of them for ambiguities.
Addresses #947Closes#947
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
AssignmentExpressions could not access their outer attributes properly,
since they were being eagerly moved into the `IdentifierExpr` type they
are based on. The base `OperatorExpr` class would thus end up with an
empty vector of outer attributes
When trying to figure out if a match can follow another, we must figure
out whether or not that match is in the follow-set of the other. If that
match is zeroable (i.e a repetition using the * or ? kleene operators),
then we must be able to check the match after them: should our current
match not be present, the match after must be part of the follow-set.
This commits allows us to performs such checks properly and to "look
past" zeroable matches. This is not done with any lookahead, simply by
keeping a list of pointers to possible previous matches and checking all
of them for ambiguities.
1043: implement include_bytes! and include_str! macros r=CohenArthur a=dafaust
Implement the include_bytes! and include_str! builtin macros.
Addresses: #927
1064: Handle :tt fragments properly r=CohenArthur a=CohenArthur
:tt fragments stand for token trees, and are composed of either a token,
or a delimited token tree, which is a token tree surrounded by
delimiters (parentheses, curly brackets or square brackets).
This should allow us to handle a lot more macros, including extremely
powerful macro patterns such as TT munchers
Co-authored-by: David Faust <david.faust@oracle.com>
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
1054: Fix overzealous follow set ambiguity r=CohenArthur a=CohenArthur
When checking if a follow-up is valid, we previously always returned
false when comparing with MacroMatchRepetitions. This is however
invalid, as we should be comparing with the first match of the
repetition to be sure.
Closes#1053
Addresses #947
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
:tt fragments stand for token trees, and are composed of either a token,
or a delimited token tree, which is a token tree surrounded by
delimiters (parentheses, curly brackets or square brackets).
This should allow us to handle a lot more macros, including extremely
powerful macro patterns such as TT munchers
When checking if a follow-up is valid, we previously always returned
false when comparing with MacroMatchRepetitions. This is however
invalid, as we should be comparing with the first match of the
repetition to be sure.
Philip Herron
bors[bot]
liushuyu
Arthur Cohen
Romain Naour
David Faust
CohenArthur