[jira] [Resolved] (THRIFT-5500) Uncompilable code when .thrift struct 'System' exists
[ https://issues.apache.org/jira/browse/THRIFT-5500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5500. Fix Version/s: 0.16.0 Assignee: Jens Geyer Resolution: Fixed > Uncompilable code when .thrift struct 'System' exists > - > > Key: THRIFT-5500 > URL: https://issues.apache.org/jira/browse/THRIFT-5500 > Project: Thrift > Issue Type: Bug > Components: netstd - Compiler >Affects Versions: 0.15.0 > Environment: Visual Studio 2022 > .netstandard-2.0 Project >Reporter: Jonas Marty >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.16.0 > > Attachments: image-2022-01-20-14-27-34-063.png, > image-2022-01-20-14-37-18-452.png > > Time Spent: 20m > Remaining Estimate: 0h > > If you have an struct in your .thrift definition with the name 'System', the > thrift compile generates uncompilable code for the Equals() method. As the > namespace 'System' gets interpreted as class. It could be fixed with > prefixing the System.Object.Equals() calls with 'global::' as it is done > nearly everywhere else where non simple types are used. > !image-2022-01-20-14-27-34-063.png|width=944,height=113! > The following compiles: > !image-2022-01-20-14-37-18-452.png|width=918,height=99! > Yes I also think naming a struct 'System' is not a good idea, but here we are > ;) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (THRIFT-5500) Uncompilable code when .thrift struct 'System' exists
[ https://issues.apache.org/jira/browse/THRIFT-5500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5500: --- Language: (was: C#) > Uncompilable code when .thrift struct 'System' exists > - > > Key: THRIFT-5500 > URL: https://issues.apache.org/jira/browse/THRIFT-5500 > Project: Thrift > Issue Type: Bug > Components: netstd - Compiler >Affects Versions: 0.15.0 > Environment: Visual Studio 2022 > .netstandard-2.0 Project >Reporter: Jonas Marty >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.16.0 > > Attachments: image-2022-01-20-14-27-34-063.png, > image-2022-01-20-14-37-18-452.png > > Time Spent: 20m > Remaining Estimate: 0h > > If you have an struct in your .thrift definition with the name 'System', the > thrift compile generates uncompilable code for the Equals() method. As the > namespace 'System' gets interpreted as class. It could be fixed with > prefixing the System.Object.Equals() calls with 'global::' as it is done > nearly everywhere else where non simple types are used. > !image-2022-01-20-14-27-34-063.png|width=944,height=113! > The following compiles: > !image-2022-01-20-14-37-18-452.png|width=918,height=99! > Yes I also think naming a struct 'System' is not a good idea, but here we are > ;) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [thrift] Jens-G merged pull request #2507: THRIFT-5500 uncompilable code when a .thrift struct named 'System' is present
Jens-G merged pull request #2507: URL: https://github.com/apache/thrift/pull/2507 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@thrift.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (THRIFT-5500) Uncompilable code when .thrift struct 'System' exists
[ https://issues.apache.org/jira/browse/THRIFT-5500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5500: --- Summary: Uncompilable code when .thrift struct 'System' exists (was: [netstd] Uncompilable code when .thrift struct 'System' exists) > Uncompilable code when .thrift struct 'System' exists > - > > Key: THRIFT-5500 > URL: https://issues.apache.org/jira/browse/THRIFT-5500 > Project: Thrift > Issue Type: Bug > Components: netstd - Compiler >Affects Versions: 0.15.0 > Environment: Visual Studio 2022 > .netstandard-2.0 Project >Reporter: Jonas Marty >Priority: Minor > Attachments: image-2022-01-20-14-27-34-063.png, > image-2022-01-20-14-37-18-452.png > > Time Spent: 10m > Remaining Estimate: 0h > > If you have an struct in your .thrift definition with the name 'System', the > thrift compile generates uncompilable code for the Equals() method. As the > namespace 'System' gets interpreted as class. It could be fixed with > prefixing the System.Object.Equals() calls with 'global::' as it is done > nearly everywhere else where non simple types are used. > !image-2022-01-20-14-27-34-063.png|width=944,height=113! > The following compiles: > !image-2022-01-20-14-37-18-452.png|width=918,height=99! > Yes I also think naming a struct 'System' is not a good idea, but here we are > ;) -- This message was sent by Atlassian Jira (v8.20.1#820001)
Branch 0.16.0
Hi all, just created a release branch for 0.16.0. Unless we hit some serious issue in the meantime I am going to prepare the release around end of January. Have fun, JensG
[jira] [Updated] (THRIFT-3877) C++ library don't work with HTTP (csharp server, cpp client; need cross test enhancement)
[ https://issues.apache.org/jira/browse/THRIFT-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-3877: --- Summary: C++ library don't work with HTTP (csharp server, cpp client; need cross test enhancement) (was: C++: library don't work with HTTP (csharp server, cpp client; need cross test enhancement)) > C++ library don't work with HTTP (csharp server, cpp client; need cross test > enhancement) > - > > Key: THRIFT-3877 > URL: https://issues.apache.org/jira/browse/THRIFT-3877 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.3, 0.10.0 > Environment: Windows 7, Visual Studio 2013 (C#), Qt 5.7 (MSVC 12). > Thrift from git repo, SHA-1: 5a3f855b4e6882184f13c698855c877241144a12 (master) >Reporter: Sergey Fasman >Assignee: James E. King III >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > Client on C++. > Tested on C# HTTP server and client — work ideal. > Then create client on C++. Client after request starts infinitly wait for > data. > For example, JSON protocol read data symbol by symbol, when trying read: it > always try to call recv function (even all data already received). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (THRIFT-5424) Cut release 0.14.2
[ https://issues.apache.org/jira/browse/THRIFT-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer closed THRIFT-5424. -- > Cut release 0.14.2 > -- > > Key: THRIFT-5424 > URL: https://issues.apache.org/jira/browse/THRIFT-5424 > Project: Thrift > Issue Type: Task > Components: Java - Library >Affects Versions: 0.14.1 >Reporter: Andrey Yegorov >Assignee: Jens Geyer >Priority: Critical > Fix For: 0.14.2 > > > libthrift release 0.13.0 (and 0.12.0) has vulnerabilities, such as > CVE-2019-0205 , CVE-2019-0210 , CVE-2020-13949 > https://github.com/advisories/GHSA-g2fg-mr77-6vrm > Unfortunately, upgrade to 0.14.1 is blocked by > https://issues.apache.org/jira/browse/THRIFT-5383 which is fixed in > [apache/thrift#2366|https://github.com/apache/thrift/pull/2366] > We'll need 0.14.2 - with working json parsing and fixed vulnerabilities. > For more context please see: [https://github.com/apache/bookkeeper/pull/2695] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (THRIFT-5495) Go lib server not close client when shutdown
[
https://issues.apache.org/jira/browse/THRIFT-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5495:
---
Fix Version/s: (was: 0.16.0)
> Go lib server not close client when shutdown
>
>
> Key: THRIFT-5495
> URL: https://issues.apache.org/jira/browse/THRIFT-5495
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.15.0
>Reporter: XiongYuesen
>Assignee: XiongYuesen
>Priority: Major
> Time Spent: 12h 20m
> Remaining Estimate: 0h
>
> If there is client connection and no data is send，we will encounter hang
> druing server stop:
> 1>If transport factory conf with socket timeout,we will hang until the
> deadline of the socket
> 2>If transport factory conf without socket timeout,we will hang forever
> Stack As below:
> goroutine 140800 [IO wait, 2706 minutes]:
> internal/poll.runtime_pollWait(0x7fbf804fb100, 0x72)
> runtime/netpoll.go:234 +0x89
> internal/poll.(*pollDesc).wait(0xc009087700, 0xc008196000, 0x0)
> internal/poll/fd_poll_runtime.go:84 +0x32
> internal/poll.(*pollDesc).waitRead(...)
> internal/poll/fd_poll_runtime.go:89
> internal/poll.(*FD).Read(0xc009087700, \{0xc008196000, 0x1, 0x1})
> internal/poll/fd_unix.go:167 +0x25a
> net.(*netFD).Read(0xc009087700, \{0xc008196000, 0x0, 0xc0061089b8})
> net/fd_posix.go:56 +0x29
> net.(*conn).Read(0xc007c98038, \{0xc008196000, 0x0, 0xc006108978})
> net/net.go:183 +0x45
> github.com/apache/thrift/lib/go/thrift.(*socketConn).Read(0x246aae0,
> \{0xc008196000, 0xc0058b4ed0, 0x246aae0})
> github.com/apache/thrift@v0.15.0/lib/go/thrift/socket_conn.go:101 +0x44
> github.com/apache/thrift/lib/go/thrift.(*TSocket).Read(0xc003555460,
> \{0xc008196000, 0x1, 0x1})
> github.com/apache/thrift@v0.15.0/lib/go/thrift/socket.go:221 +0x67
> bufio.(*Reader).Read(0xc005657320, \{0xc001da1000, 0x1000, 0x203000})
> bufio/bufio.go:227 +0x1b4
> github.com/apache/thrift/lib/go/thrift.(*TBufferedTransport).Read(0xc0035554a0,
> \{0xc001da1000, 0x431e10, 0x64})
> github.com/apache/thrift@v0.15.0/lib/go/thrift/buffered_transport.go:67
> +0x45
> bufio.(*Reader).Read(0xc005657380, \{0xc0090877f0, 0x4, 0x4b5bac0})
> bufio/bufio.go:227 +0x1b4
> io.ReadAtLeast(\{0x30c0520, 0xc005657380}, \{0xc0090877f0, 0x4, 0x4}, 0x4)
> io/io.go:328 +0x9a
> io.ReadFull(...)
> io/io.go:347
> github.com/apache/thrift/lib/go/thrift.(*TFramedTransport).readFrame(0xc009087780)
> github.com/apache/thrift@v0.15.0/lib/go/thrift/framed_transport.go:199 +0x3c
> github.com/apache/thrift/lib/go/thrift.(*TFramedTransport).Read(0xc009087780,
> \{0xc0090877f0, 0x1, 0x4})
> github.com/apache/thrift@v0.15.0/lib/go/thrift/framed_transport.go:148
> +0x130
> github.com/apache/thrift/lib/go/thrift.(*TFramedTransport).ReadByte(0xc009087780)
> github.com/apache/thrift@v0.15.0/lib/go/thrift/framed_transport.go:157 +0x2e
> github.com/apache/thrift/lib/go/thrift.(*TCompactProtocol).readByteDirect(...)
> github.com/apache/thrift@v0.15.0/lib/go/thrift/compact_protocol.go:766
> github.com/apache/thrift/lib/go/thrift.(*TCompactProtocol).ReadMessageBegin(0xc008765040,
> \{0x311a118, 0xc00319ede0})
> github.com/apache/thrift@v0.15.0/lib/go/thrift/compact_protocol.go:367 +0x62
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (THRIFT-5476) Deprecate Common Lisp support
[ https://issues.apache.org/jira/browse/THRIFT-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5476. Resolution: Fixed > Deprecate Common Lisp support > - > > Key: THRIFT-5476 > URL: https://issues.apache.org/jira/browse/THRIFT-5476 > Project: Thrift > Issue Type: Improvement > Components: Common LISP - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Fix For: 0.16.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Deprecate and remove Common Lisp language bindings due to the lack active > maintainers. > See also the [mailing list > tread|http://mail-archives.apache.org/mod_mbox/thrift-dev/202110.mbox/%3C9014BF98D742484E8B04E052EEE8668B%40HAGGIS%3E]. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (THRIFT-5476) Deprecate Common Lisp support
[
https://issues.apache.org/jira/browse/THRIFT-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436465#comment-17436465
]
Jens Geyer edited comment on THRIFT-5476 at 1/20/22, 7:25 PM:
--
Deprecation message added, failing cl builds commented out.
{-}*Leaving ticket open until intentionally* until final removal is
completed{-}.
was (Author: jensg):
Deprecation message added, failing cl builds commented out.
*Leaving ticket open until intentionally* until final removal is completed.
> Deprecate Common Lisp support
> -
>
> Key: THRIFT-5476
> URL: https://issues.apache.org/jira/browse/THRIFT-5476
> Project: Thrift
> Issue Type: Improvement
> Components: Common LISP - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.16.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Deprecate and remove Common Lisp language bindings due to the lack active
> maintainers.
> See also the [mailing list
> tread|http://mail-archives.apache.org/mod_mbox/thrift-dev/202110.mbox/%3C9014BF98D742484E8B04E052EEE8668B%40HAGGIS%3E].
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (THRIFT-5501) Remove Common Lisp support
Jens Geyer created THRIFT-5501: -- Summary: Remove Common Lisp support Key: THRIFT-5501 URL: https://issues.apache.org/jira/browse/THRIFT-5501 Project: Thrift Issue Type: Sub-task Components: Common LISP - Compiler Affects Versions: 0.16.0 Reporter: Jens Geyer Assignee: Jens Geyer -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (THRIFT-5483) Support customized comparator in Java
[
https://issues.apache.org/jira/browse/THRIFT-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5483:
---
Description:
The generated comparator (and hash code) of Thrift Structs compares two objects
by all of their fields, which may cause trouble when used in hash structures.
For example, I define a struct like:
{code:java}
struct Person{
1: required i64 id
2: required string phoneNumber
}
{code}
The id of a Person is final, while its phoneNumber can be changed.
Then I use it as a key in a map to record a Person's supervisors:
{code:java}
Map supervisorMap;
{code}
Apparently, as the generated comparator of Person will use both id and
phoneNumber for comparison and hash if I change the phoneNumber of a Person, I
can no longer get it from the map as its hash value changes and it will be
distributed to another hash slot.
Therefore, I wish I could specify the fields that are to be used in comparator
and hash code generation. One preferable grammar may be like:
{code:java}
struct Person{
1: required comparable i64 id
2: required string phoneNumber
}
{code}
Then the generated comparator and hash code will only use fields marked with
`comparable`, and if no fields are marked with comparable, Java's default
comparison and hashcode (using object address) will be used.
was:
The generated comparator (and hash code) of Thrift Structs compares two objects
by all of their fields, which may cause trouble when used in hash structures.
For example, I define a struct like:
{code:thrift}
struct Person{
1: required i64 id
2: required string phoneNumber
}
{code}
The id of a Person is final, while its phoneNumber can be changed.
Then I use it as a key in a map to record a Person's supervisors:
{code:java}
Map supervisorMap;
{code}
Apparently, as the generated comparator of Person will use both id and
phoneNumber for comparison and hash if I change the phoneNumber of a Person, I
can no longer get it from the map as its hash value changes and it will be
distributed to another hash slot.
Therefore, I wish I could specify the fields that are to be used in comparator
and hash code generation. One preferable grammar may be like:
{code:thrift}
struct Person{
1: required comparable i64 id
2: required string phoneNumber
}
{code}
Then the generated comparator and hash code will only use fields marked with
`comparable`, and if no fields are marked with comparable, Java's default
comparison and hashcode (using object address) will be used.
> Support customized comparator in Java
> -
>
> Key: THRIFT-5483
> URL: https://issues.apache.org/jira/browse/THRIFT-5483
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Compiler
>Reporter: Tian Jiang
>Priority: Major
>
> The generated comparator (and hash code) of Thrift Structs compares two
> objects by all of their fields, which may cause trouble when used in hash
> structures.
> For example, I define a struct like:
> {code:java}
> struct Person{
> 1: required i64 id
> 2: required string phoneNumber
> }
> {code}
> The id of a Person is final, while its phoneNumber can be changed.
> Then I use it as a key in a map to record a Person's supervisors:
> {code:java}
> Map supervisorMap;
> {code}
> Apparently, as the generated comparator of Person will use both id and
> phoneNumber for comparison and hash if I change the phoneNumber of a Person,
> I can no longer get it from the map as its hash value changes and it will be
> distributed to another hash slot.
> Therefore, I wish I could specify the fields that are to be used in
> comparator and hash code generation. One preferable grammar may be like:
> {code:java}
> struct Person{
> 1: required comparable i64 id
> 2: required string phoneNumber
> }
> {code}
> Then the generated comparator and hash code will only use fields marked with
> `comparable`, and if no fields are marked with comparable, Java's default
> comparison and hashcode (using object address) will be used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (THRIFT-5497) Change the C++ representation of binary be std::basic_string
[ https://issues.apache.org/jira/browse/THRIFT-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5497: --- Language: (was: C++) > Change the C++ representation of binary be std::basic_string > --- > > Key: THRIFT-5497 > URL: https://issues.apache.org/jira/browse/THRIFT-5497 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler >Reporter: Richard H. Gumpertz >Priority: Minor > Attachments: binary_string_2022.01.17_#2.h > > > I would like to change the C++ representation of binary from "std::string" to > "std::basic_string". This would allow C++ templates to > distinguish the Thrift type "string" from "binary". > If nothing else, ::apached::thrift::to_string could print binary differently > than string. Currently, it can get pretty ugly when one calls printTo on a > struct containing a binary field that has data that is not readable! > There is an issue as to how they should be displayed by default; using > \xDE\xAD\xBE\xEF with a \ before every byte seems ugly. Alternativlely, > "DEADBEEF"_x because it could also be used as input if the C++ operator""_x > is defined by the user? Alternatively just or <27-byte binary> > (mirroring for unset fields), hiding the contents? Perhaps leave > to_string(std::basic_string &value) undefined and force the > user to define it if needed? Thoughts & suggestions??? > Given that such a change could break existing code, it should probably be > enabled under a new thrift compiler option to --gen cpp. I haven't come up > with a good name for such an option yet: --gen cpp:binary_as_unsigned_string > is explicit but wordy. Any suggestions??? > I would be willing to do the work necessary to add the relevant code if there > are no volunteers who have a better understanding of precisely what code > would have to be updated (or at least help me find such code) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (THRIFT-5483) Support customized comparator in Java
[
https://issues.apache.org/jira/browse/THRIFT-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5483:
---
Component/s: Java - Compiler
> Support customized comparator in Java
> -
>
> Key: THRIFT-5483
> URL: https://issues.apache.org/jira/browse/THRIFT-5483
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Compiler
>Reporter: Tian Jiang
>Priority: Major
>
> The generated comparator (and hash code) of Thrift Structs compares two
> objects by all of their fields, which may cause trouble when used in hash
> structures.
> For example, I define a struct like:
> {code:thrift}
> struct Person{
> 1: required i64 id
> 2: required string phoneNumber
> }
> {code}
> The id of a Person is final, while its phoneNumber can be changed.
> Then I use it as a key in a map to record a Person's supervisors:
> {code:java}
> Map supervisorMap;
> {code}
> Apparently, as the generated comparator of Person will use both id and
> phoneNumber for comparison and hash if I change the phoneNumber of a Person,
> I can no longer get it from the map as its hash value changes and it will be
> distributed to another hash slot.
> Therefore, I wish I could specify the fields that are to be used in
> comparator and hash code generation. One preferable grammar may be like:
> {code:thrift}
> struct Person{
> 1: required comparable i64 id
> 2: required string phoneNumber
> }
> {code}
> Then the generated comparator and hash code will only use fields marked with
> `comparable`, and if no fields are marked with comparable, Java's default
> comparison and hashcode (using object address) will be used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (THRIFT-5491) add benchmark for partial deserialization
[ https://issues.apache.org/jira/browse/THRIFT-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5491: --- Language: (was: java) > add benchmark for partial deserialization > - > > Key: THRIFT-5491 > URL: https://issues.apache.org/jira/browse/THRIFT-5491 > Project: Thrift > Issue Type: Test > Components: Java - Library >Reporter: Bhalchandra Pandit >Assignee: Bhalchandra Pandit >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add JMH based benchmark that shows performance advantages of partial > deserialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (THRIFT-5491) add benchmark for partial deserialization
[ https://issues.apache.org/jira/browse/THRIFT-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5491: --- Component/s: Java - Library > add benchmark for partial deserialization > - > > Key: THRIFT-5491 > URL: https://issues.apache.org/jira/browse/THRIFT-5491 > Project: Thrift > Issue Type: Test > Components: Java - Library >Reporter: Bhalchandra Pandit >Assignee: Bhalchandra Pandit >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add JMH based benchmark that shows performance advantages of partial > deserialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (THRIFT-5497) Change the C++ representation of binary be std::basic_string
[ https://issues.apache.org/jira/browse/THRIFT-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5497: --- Component/s: C++ - Compiler > Change the C++ representation of binary be std::basic_string > --- > > Key: THRIFT-5497 > URL: https://issues.apache.org/jira/browse/THRIFT-5497 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler >Reporter: Richard H. Gumpertz >Priority: Minor > Attachments: binary_string_2022.01.17_#2.h > > > I would like to change the C++ representation of binary from "std::string" to > "std::basic_string". This would allow C++ templates to > distinguish the Thrift type "string" from "binary". > If nothing else, ::apached::thrift::to_string could print binary differently > than string. Currently, it can get pretty ugly when one calls printTo on a > struct containing a binary field that has data that is not readable! > There is an issue as to how they should be displayed by default; using > \xDE\xAD\xBE\xEF with a \ before every byte seems ugly. Alternativlely, > "DEADBEEF"_x because it could also be used as input if the C++ operator""_x > is defined by the user? Alternatively just or <27-byte binary> > (mirroring for unset fields), hiding the contents? Perhaps leave > to_string(std::basic_string &value) undefined and force the > user to define it if needed? Thoughts & suggestions??? > Given that such a change could break existing code, it should probably be > enabled under a new thrift compiler option to --gen cpp. I haven't come up > with a good name for such an option yet: --gen cpp:binary_as_unsigned_string > is explicit but wordy. Any suggestions??? > I would be willing to do the work necessary to add the relevant code if there > are no volunteers who have a better understanding of precisely what code > would have to be updated (or at least help me find such code) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [thrift] Jonas-Marty opened a new pull request #2507: THRIFT-5500 uncompilable code when a .thirft struct named 'System' is present
Jonas-Marty opened a new pull request #2507: URL: https://github.com/apache/thrift/pull/2507 https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-5500 Fixes by adding `global::` in front of the call to `System.Object.Equals(...)` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@thrift.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (THRIFT-5500) [netstd] Uncompilable code when .thrift struct 'System' exists
[ https://issues.apache.org/jira/browse/THRIFT-5500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonas Marty updated THRIFT-5500: Summary: [netstd] Uncompilable code when .thrift struct 'System' exists (was: Uncompilable code when .thrift struct 'System' exists) > [netstd] Uncompilable code when .thrift struct 'System' exists > -- > > Key: THRIFT-5500 > URL: https://issues.apache.org/jira/browse/THRIFT-5500 > Project: Thrift > Issue Type: Bug > Components: netstd - Compiler >Affects Versions: 0.15.0 > Environment: Visual Studio 2022 > .netstandard-2.0 Project >Reporter: Jonas Marty >Priority: Minor > Attachments: image-2022-01-20-14-27-34-063.png, > image-2022-01-20-14-37-18-452.png > > > If you have an struct in your .thrift definition with the name 'System', the > thrift compile generates uncompilable code for the Equals() method. As the > namespace 'System' gets interpreted as class. It could be fixed with > prefixing the System.Object.Equals() calls with 'global::' as it is done > nearly everywhere else where non simple types are used. > !image-2022-01-20-14-27-34-063.png|width=944,height=113! > The following compiles: > !image-2022-01-20-14-37-18-452.png|width=918,height=99! > Yes I also think naming a struct 'System' is not a good idea, but here we are > ;) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (THRIFT-5500) Uncompilable code when .thrift struct 'System' exists
Jonas Marty created THRIFT-5500: --- Summary: Uncompilable code when .thrift struct 'System' exists Key: THRIFT-5500 URL: https://issues.apache.org/jira/browse/THRIFT-5500 Project: Thrift Issue Type: Bug Components: netstd - Compiler Affects Versions: 0.15.0 Environment: Visual Studio 2022 .netstandard-2.0 Project Reporter: Jonas Marty Attachments: image-2022-01-20-14-27-34-063.png, image-2022-01-20-14-37-18-452.png If you have an struct in your .thrift definition with the name 'System', the thrift compile generates uncompilable code for the Equals() method. As the namespace 'System' gets interpreted as class. It could be fixed with prefixing the System.Object.Equals() calls with 'global::' as it is done nearly everywhere else where non simple types are used. !image-2022-01-20-14-27-34-063.png|width=944,height=113! The following compiles: !image-2022-01-20-14-37-18-452.png|width=918,height=99! Yes I also think naming a struct 'System' is not a good idea, but here we are ;) -- This message was sent by Atlassian Jira (v8.20.1#820001)
