Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C++] Build fix/correction for UTF32 conversion. #1908

Merged
merged 11 commits into from Jun 11, 2017
Merged

[C++] Build fix/correction for UTF32 conversion. #1908

merged 11 commits into from Jun 11, 2017

Conversation

mike-lischke
Copy link
Member

Adds a few fixes after the recent UTF32 conversion changes. Also fixes some warnings.

mike-lischke and others added 11 commits April 19, 2017 13:47
The twisted way to create a javac like output path breaks many use cases, including very simple ones with lexer + parser grammar in a relative subdir (where parser generation doesn't find the lexer tokens). Additionally, not all projects prefer to have their generated files in an output folder which is comprised of the given output path and the subdir given for the grammar files. The check for absolute paths as decision criterion is a weak one anyway - it makes simple usage difficult and doesn't deal with path expansion on all platforms.

If a javac like output path is required it should be easy to construct this upfront and provide it as the output path parameter, instead of implicitely creating it. This patch simplifies things without any WTF moments because generated files end up and unexpected locations. It now can deal with simple cases (no output, no grammar subdir) up to complicated cases (nested and/or absolute output dir, multiple grammar subfolders).
Removed some duplicate classes there too.
Also made converter local vars in conversion routines, instead of static global vars.
@parrt parrt added this to the 4.7.1 milestone Jun 11, 2017
@parrt parrt merged commit e9155ef into antlr:master Jun 11, 2017
@mike-lischke mike-lischke deleted the master-build-fix branch June 12, 2017 07:37
@ericvergnaud
Copy link
Contributor

TestCompositeParsers still fails with a compiler error, maybe you need to have a second look?

@mike-lischke
Copy link
Member Author

@ericvergnaud Where do you see a compiler error? What fails is what always fails since last fall, job runtime exceeded maximum: https://travis-ci.org/antlr/antlr4/jobs/241708892

@ericvergnaud
Copy link
Contributor

@mike-lischke look in https://travis-ci.org/antlr/antlr4/jobs/241757707, which is from the latest master + non cpp changes

@mike-lischke
Copy link
Member Author

mike-lischke commented Jun 25, 2017

That's a completely different branch. Why do you post the failure notice in this PR? I have a pull request (#1910) for that failure.

@ericvergnaud
Copy link
Contributor

ericvergnaud commented Jun 25, 2017 via email

@mike-lischke
Copy link
Member Author

Now I see what you mean. Still it's the wrong PR. The one where the built broke was #1907 which had been merged short before this one. Maybe @parrt can merge the fix in #1910 quickly, which is just a simple template change.

@ericvergnaud
Copy link
Contributor

Agreed

@parrt
Copy link
Member

parrt commented Jun 25, 2017

Hi guys, i think i've caught up with merges related to bug fixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants